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][jakartaee-spec-project-leads]Automatic Module Names inJakarta EE 9

Lance,
Since JTA 2.0 will only contain the jakarta.transaction package (not the java.transaction.xa package), then I'm not clear on why changing this the Automatic Module Name to "jakarta.transaction" would cause any breakage.  Or, I should say any more breakage than the package renaming is already causing...  I mean even if we leave this module name as java.transaction, the contained API will have changed to use the jakarta.transaction package name, so the app is already making changes to accommodate.  And, if the application requires both modules, then they could specify both java.transaction and jakarta.transaction as dependencies.

What am I missing?

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn:
https://www.linkedin.com/in/kevinwsutter



From:        Lance Andersen <LANCE.ANDERSEN@xxxxxxxxxx>
To:        jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc:        Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:        07/22/2020 15:14
Subject:        [EXTERNAL] Re: [jakartaee-platform-dev] [jakarta.ee-spec][jakartaee-spec-project-leads]Automatic Module Names inJakarta EE 9
Sent by:        jakartaee-platform-dev-bounces@xxxxxxxxxxx




I would leave the Jakarta Transactions automatic module name as java.transaction at least for now.  Changing this could potentially break existing apps that are relying on this name since I added it to the JTA 1.3 spec.

Certainly changing the module name going forward is an option, but given this module will be used along with java.transaction.xa module I would hold off for a bit to think this through in detail.

Best
Lance

On Jul 22, 2020, at 3:36 PM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:

Werner,
I agree that there are several options outlined in the document that Scott started:  
https://docs.google.com/document/d/1LAAHKPJyREky9fEKv0xFd9IRDgXB58It53ryfyrNPtg/edit#

I would still like to get input from the various Specification Projects that are affected.  Even if an "executive decision" has to be made, I'd like to do with proper and full input.


At the Spec Committee call today, the discussion centered around doing minimal work for Jakarta EE 9.  Option F in the above referenced doc seems to be closest to that desire.  But, Option E is also very close with not much difference in effort.  (I created Option E because the Option D in the doc didn't match the description of Option D in this note string.  I just wanted to be very clear on the intent.)


So, please, if you have an existing Automatic Module Name defined or an explicit module-info.class file defined, read through the options in the reference doc and provide feedback.  Thanks!

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM

e-mail:  sutter@xxxxxxxxxx    Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn:
https://www.linkedin.com/in/kevinwsutter



From:        
Werner Keil <werner.keil@xxxxxxx>
To:        
jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc:        
Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:        
07/22/2020 13:59
Subject:        
[EXTERNAL] Re: [jakartaee-platform-dev] [jakarta.ee-spec][jakartaee-spec-project-leads]Automatic Module Names inJakarta EE 9
Sent by:        
jakartaee-platform-dev-bounces@xxxxxxxxxxx



There is more than just placing them, but I said we should not bother to "specify" anything in Jakarta EE because that has been done for us on the JDK level.

 


Unfortunately there are almost more options than people to vote on it seems in the document Scott started.
Who will vote on those, the members of the Spec Committee or someone else?

 


The specs that created explicit module-info definitions should not be deprived because it may turn application developers away from Jakarta EE, similar if the modules kept changing multiple times after what we presented as "Big Bang" where everything is renamed.
"Yet another Big Bang" in Jakarta EE 9.1 or 10 would send a bad signal even if it was just for the module names.

 


Werner

 


From: Thomas Watson
Sent:
Wednesday, July 22, 2020 18:09
To:
jakartaee-platform-dev@xxxxxxxxxxx
Subject:
Re: [jakartaee-platform-dev][jakarta.ee-spec][jakartaee-spec-project-leads]Automatic Module Names inJakarta EE 9

 


Are the module names we define seen as useful for application developers at this point?  I see how they are useful for Jetty's ability to run on the module path.  But my understanding is that applications are still loaded outside of a module layer.  At least until something like https://github.com/eclipse/jetty.project/issues/2895is implemented.

 


Werner seems to suggest you can simply place all your application modules along with your spec and platform impl modules on the module path and it all "just works".  In my experience it has never "just worked" from an application perspective without much more thought and time to implement it correctly.

 


I do appreciate that platform implementers want a consistent module name for their own needs at this time.  But as of now I see that as an issue for the implementers and not necessarily for the application developers at larger.  At least until the Jakarta specification defines how modular applications are loaded.  I do believe that scenario will have different rules than how the platform defines applications are loaded today, for example how WARs are loaded at runtime.

 


In the end I do not want to push for the absolute removal of all module names.  I never suggested removing existing module-info definitions.  I certainly didn't intend to trample on past legacies.  But to insist that these names have to be defined now and absolutely can never change in the future when we don't fully understand how a JPMS defined Jakarta application would look and load at runtime seems premature.

 


Tom

 

 


----- Original message -----
From: Joakim Erdfelt <
joakim.erdfelt@xxxxxxxxx>
Sent by:
jakartaee-platform-dev-bounces@xxxxxxxxxxx
To: jakartaee-platform developer discussions <
jakartaee-platform-dev@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] [jakarta.ee-spec][jakartaee-spec-project-leads]Automatic Module Names in Jakarta EE 9
Date: Wed, Jul 22, 2020 10:32 AM

I'm in the "do this change now" camp.

 


Eclipse Jetty 10 on Jakarta EE 8 uses JPMS just fine. (we had to modify and release our own jakarta jars because Jakarta EE didn't)
Eclipse Jetty 11 on Jakarta EE 9 uses JPMS as well. (we had to modify and release our own jakarta jars because Jakarta EE didn't)

 


We have active users on both, today.

 


Of course, our usage is far more limited than the whole of Jakarta EE.
(Only really servlet, jsp, websocket with related tech)

 


But this failure to address this is causing something in the wider community that hasn't been brought up yet.

 


Projects that need the JPMS naming and would rather "do it themselves" by modifying the released jakarta jars with module-info and releasing them on maven central under new coordinate spaces.
Now we have broken dependency conflict resolution on the global central repository system.

 


Do we really want that?

 


- Joakim

 


On Wed, Jul 22, 2020 at 10:14 AM Werner Keil <werner.keil@xxxxxxx> wrote:
There is, it’s called JPMS and once you have a module declaration (both explitic or automatic) in the module-path this works, the behavior is specified by the Java SE platform and I see no reason why we would have to do anything in Jakata EE on that.

 


As long as those specs that did a great Job in properly declaring module-info are not forced to destroy that (including Services and lots of other stuff) and rip it out only to put it back in again, I guess I could live with removing the automatic-module-name from the POM because that is a lot less work and could even be commented out for now.

 


However, there shall be no renaming later, so if it’s called "jakarta.activation" or "jakarta.json" in a proper module-info, then it must not change.
Especially those two are fairly independent and used not just by Jakarta EE components or different specs, they are used by other types of applications including Maven plugins etc. or by the Spring stack and there automatic-module-name is also what every Spring JAR I saw lately does, therefore we’d lose an advantage compared to Spring if we removed the automatic-module-name now, but it would help clean the mess that so far only exists in those automatic module names.

 


Werner

 


From: Thomas Watson
Sent:
Wednesday, July 22, 2020 16:54
To:
jakartaee-platform-dev@xxxxxxxxxxx
Subject:
Re: [jakartaee-platform-dev] [jakarta.ee-spec][jakartaee-spec-project-leads]Automatic Module Names in Jakarta EE 9

 


How are we intending developers to use the module names that get specified by the spec JARs?  I have not seen any indication that there is a standards based way to build a Jakarta EE application out of JPMS modules.  Furthermore there is no specified behavior for how a Jakarta EE platform implementation would load such an application as modules at runtime.  Any such support will have to be implementation specific and that implementation likely will need to have a coherent set of modules it provides to implement the platform out of modules.  Any such application will likely need to target that specific implementation until there is a standard way of doing this.  If Jakarta ever decides modules have to be supported at runtime I am sure it will likely look different from any decisions we try to make today for module names.

 


For this reason I agree with Scott that it probably does more good to remove the Automatic-Module-Name headers from all specification JARs.

 


Tom

 

 


----- Original message -----
From: Scott Stark <
starksm64@xxxxxxxxx>
Sent by:
jakartaee-platform-dev-bounces@xxxxxxxxxxx
To: Jakarta specification discussions <
jakarta.ee-spec@xxxxxxxxxxx>
Cc: JakartaEE Spec Project Leadership discussions <
jakartaee-spec-project-leads@xxxxxxxxxxx>, jakartaee-platform-dev-bounces@xxxxxxxxxxx, jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] [jakarta.ee-spec] [jakartaee-spec-project-leads]Automatic Module Names in Jakarta EE 9
Date: Wed, Jul 22, 2020 9:48 AM

Then that is heading in the direction of the non-stated option D to remove all Automatic-Modue-Name headers. Doing no work around this issue for Jakarta EE 9 leaves the headers in a bit of a mess. It would seem that the simplest change timewise would be to mandate their removal.  I think we need to draft a voting resolution on 4 different options with the pros and cons of each and decide which route to take. I'll create a draft for comments.

 


On Wed, Jul 22, 2020 at 9:37 AM Lance Andersen <lance.andersen@xxxxxxxxxx> wrote:
Hi Kevin,

 

 


On Jul 22, 2020, at 10:12 AM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:

 


Agree, Lance.  That's why I don't want to push this into the Jakarta EE 9 schedule.  We may come up with what we think is the right answer, but until we really dive into the JPMS impact across the Jakarta EE board, we'll probably have to make changes later.  I would prefer to leave things as-is for Jakarta EE 9 -- except for maybe the four items we have identified as getting rid of the 'java' prefix.

 


This is why we held off adding automatic module names prior to the transition to Eclipse as we felt after some lengthy internal discussions that this should only be done once and given the transition, it was best to wait.

 


Scott, I would not add the manifest element without finalizing on a name.  The intent of this element was to ease the transition to the module world, but if the name is not going to be firmed up, i would wait as it adds not value and just causes extra churn to the developers.

 


Best
Lance
_______________________________________________
jakartaee-platform-dev mailing list

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

 

 

 


_______________________________________________
jakartaee-platform-dev mailing list

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

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

 

 


 _______________________________________________
jakartaee-platform-dev mailing list

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

_______________________________________________
jakartaee-platform-dev mailing list

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


Best
Lance

------------------




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803

Lance.Andersen@xxxxxxxxxx



_______________________________________________
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