Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [jakarta.ee-spec][jakarta.ee-spec.committee][jakartaee-spec-project-leads]AutomaticModuleNamesinJakartaEE9

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:
Hi,

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.

Thanks,
Tom





On Mon, 27 Jul 2020 at 20:18, Werner Keil <werner.keil@xxxxxxx> wrote:

+1

 

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.

 

Werner

 

Sent from Mail for Windows 10

 

From: Scott Stark
Sent: Monday, July 27, 2020 21:01
To: Jakarta specification discussions
Cc: jakartaee-platform developer discussions
Subject: Re: [jakartaee-platform-dev] [jakarta.ee-spec][jakarta.ee-spec.committee][jakartaee-spec-project-leads]AutomaticModuleNamesinJakartaEE9

 

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:

Scott,

 

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.

 

Werner

 

From: Scott Stark
Sent: Monday, July 27, 2020 19:13
To: Jakarta specification discussions
Subject: Re: [jakarta.ee-spec][jakartaee-platform-dev][jakarta.ee-spec.committee][jakartaee-spec-project-leads]AutomaticModuleNamesinJakartaEE9

 

The DI AMN was added in response to this issue:

https://github.com/eclipse-ee4j/injection-api/issues/14

 

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:

Kevin,

 

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.

 

Werner

 

Sent from Mail for Windows 10

 

 

_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec

 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

Back to the top