|Re: [jakartaee-platform-dev] [jakarta.ee-spec] [jakarta.ee-spec.committee][jakartaee-spec-project-leads]AutomaticModuleNamesinJakartaEE9|
I believe that was also done
Gesendet von Mail für Windows 10
Ah, it looks like we updated it anyway and my current PR is just to update the readme anyway. Sorry for the noise.
On Thu, 10 Sep 2020 at 10:15, Tom Jenkinson <tom.jenkinson@xxxxxxxxxx> wrote:
I am unclear, was a conclusion to this thread reached (especially in regards Jakarta Transactions)?
For Jakarta Transactions I have now raised https://github.com/eclipse-ee4j/jta-api/issues/163 and have a PR for it: https://github.com/eclipse-ee4j/jta-api/pull/164
Please let me know if a decision was made so I know whether we need to try to merge this for EE9.
On Mon, 27 Jul 2020 at 20:18, Werner Keil <werner.keil@xxxxxxx> wrote:
While it was not in the 1.0 GA from last year, it is safe to consider https://repo1.maven.org/maven2/jakarta/inject/jakarta.inject-api/1.0.1/ a Service or Maintenance Release to the Jakarata EE 8 branch. And since there was no module in the old "java" namespace before I guess the new namespace in the 8.x branch looks acceptable here because there were no downstream dependencies before.
Sent from Mail for Windows 10
Right, DI did not have an AMN in the 8 platform release. User input drove a post 8 release update to include it.
I will argue on the spec meeting that I don’t see a problem with allowing API jars to include automatic module names if the project is willing to do the work. There are API jars that are used outside of the EE platform, and the slow pace of post Java 8 adoption in the EE platform should not preclude such APIs from meeting their broader community usage.
On Mon, Jul 27, 2020 at 1:15 PM Werner Keil <werner.keil@xxxxxxx> wrote:
I may get some more mail on the DI Mailing list or ws it CDI, either way, I guess you can’t rewrite history and it was not in Jakarta EE 8, so unless we agreed to make an exception here, Inject (and also CDI) would be left to a follow-up release, while Bean Validation seems good to go.
The only reason for an exception I could think of is to provide a stable dependency for CDI, should it wish to even declare a module-info in a future release and to some extent the other Frameworks including Spring which use AtInject (in the pre-Jakarta Version I assume) but most of them don’t use CDI.
The DI AMN was added in response to this issue:
However, it really should have been java.inject.
The fact that users are asking for module names brings up the issue of the usage of these api jars outside of the platform releases. An api jar that has one of its targets being Java SE usage needs to be able to evolve to adapt to the runtime users are making use of.
On Mon, Jul 27, 2020 at 9:09 AM Werner Keil <werner.keil@xxxxxxx> wrote:
Hopefully Scott can help with that.
Jakarta Inject is particularly weird, because ist automatic-module-name in the ee8 branch https://github.com/eclipse-ee4j/injection-api/blob/ee8/pom.xml already suggested it had "jakarta.inject” but the 1.0 JAR in MavenCentral has an almost empty META-INF with no such thing as a module declaration, but it released a 1.0.1 patch release this year with the module declaration.
Its codebase/branch and binaries don’t seem to match, please ask Scott to sort it out, IMO based on the 1.0 state it should be removed.
Jakarta Validation had "java.validation” in its 2.0.2 from August 2019 so that release should be part of Jakarta EE 8 and it seems good to go. I updated the In EE 8 and Issue columns accordingly.
Sent from Mail for Windows 10
jakarta.ee-spec mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
jakartaee-platform-dev mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
Back to the top