Note, the ".api" is rarely used, if that really was desired to be commonly used, then e.g. DI, CDI and Bean Validation all should use it and not just one of them. Same for Servlet where only JSP uses it, but (leaving the wrong namespace aside) the Servlet Spec doesn’t. Werner Sent from Mail for Windows 10 It has to be addressed in at least 9.1 when requiring Java 11 as at that point you do have modules, even if they are automatic, and we should not be allowing implicit automatic module names in API jars. I think the api in the module name is probably a good thing, but we have some artifact names that seemingly should be shortened to make the module name. For example, the CDI api artifact is jakarta.enterprise.cdi-api-*.jar. The enterprise seems unnecessary and the module name could just be jakarta.cdi.api for example. We should start updating the naming conventions in preparation for 9.1. On this morning's Platform call, Werner communicated the inconsistency which we have across the Jakarta EE Projects relating to the Automatic (and defined) Module Names.
Agenda/Minutes: https://docs.google.com/document/d/1EJ2ilaPhMnQqa3aw6AmwjRbBPGL3_np4uuwklgfqPZI/edit#heading=h.ncofh797vcpf
In Werner's spreadsheet, he showed how most of the Projects have avoided this exercise altogether. We have some Projects have left over defined Module Names from Java EE 8, which have been carried forward. And, some Projects that have attempted to define Automatic Module Names, but we're not consistent.
https://docs.google.com/spreadsheets/d/1g8jYG0JixO3wzZkpeyU1LMIQRhbnZ76kGtdMFE8mieE/edit#gid=0
So far, there have been four Projects that, on the surface, have defined "incorrect" module names because they used the "java." prefix -- authentication, authorization, servlet, and transaction. These four at a minimum should have the "jakarta." prefix instead (or, so was stated on the call this morning).
But, as I was talking with the Servlet team about making this type of change to define an Automatic Module Name as "jakarta.servlet", they proposed that the name should be "jakarta.servlet.api" (consistent with the other web component modules of "jakarta.el.api" and "jakarta.servlet.jsp.api"). Since we as a Platform haven't defined a naming convention for Modules, I couldn't really argue against their proposed naming convention.
https://www.eclipse.org/lists/servlet-dev/msg00233.html
Just for reference, we have also avoided the Module Naming convention in our official Jakarta EE Naming Conventions: https://wiki.eclipse.org/JakartaEE_Maven_Versioning_Rules
On this morning's call, we indicated that maybe this is something that needs to be discussed with the Spec Committee. We can still do that (I have added it to our agenda for tomorrow). But, given that we would be opening a can of worms with entertaining a Module Naming Convention, my proposal for Jakarta EE 9 is to stick with our original plan and not address this for Jakarta EE 9. If we rush a decision, it will be wrong. If we have a full-blown discussion on this topic, we're just throwing another wrench into the Jakarta EE 9 plans. And, since Jakarta EE 9's priority is Java SE 8 defining Module Names is really a moot point.
In a nutshell, here's my proposal. Please throw eggs asap so that we can move on... Thanks! - If you have a defined Module Name (module-info.class), then leave it as-is. These were carry overs from Java EE 8 and we'll just live with them as-is.
- If you have an Automatic Module Name (MANIFEST) defined, you can remove it, or leave it as-is, or you can rename it as you think the naming convention might be in the future.
- If you have Nothing related to Module Names in your API, then leave it as-is. I would not recommend adding an Automatic Module Name at this point since we don't know what the convention will be in the future.
-
Basically, don't do anything for Jakarta EE 9. Leave everything as-is. And, we'll address it later in either Jakarta EE 9.1 or 10.
(We will still need some type of disclaimer in the Platform Spec that indicates not to count on the Module Names for Jakarta EE 9 -- they will be changing in the future when we properly support JPMS Modules.)
---------------------------------------------------
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
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads |
