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

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

 

 


Back to the top