Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [jakartaee-spec-project-leads]Automatic Module Names in Jakarta EE 9


On 7/22/20 2:12 PM, Werner Keil wrote:

+1 for B

Because the only module that matters in this case is the "spec"or "${API_PACKAGE}" and you shouldn’t have to put "api" there in addition.

Plus it was not done by the prior JCP naming convention where "javax.json:javax.json-api" contained a module "java.json" and not "java.json.api”.

jsonp as such is simple yet complex enough "sample project" to experiment with JPMS name as well as _its usage_[1] by various consumers as it is provided in both forms allowed by the versioning policy[2] (an API jar file and an implementation jar file) and used in both environments - (Java) SE as well as (Jakarta) EE, so usage matrix here gets quite complex and users cannot be simply told to "compile against APIs, run with arbitrary implementation" if the name of the API and implementation jar containing APIs differs[3].

I believe that defining/understanding usage scenarios for consumption of Jakarta APIs is crucial part of getting the module naming pattern right.


[1]: (note on s/java.json/jakarta.json and wrong version number in this file which will be fixed next week)

I see no need to deploy the actual specs in a JPMS form where they would declare a module, if anybody does please advise, that IMO could be the only reason to distinguish the spec from the API while they otherwise are often synonymous.


*From: *Mark Thomas <mailto:markt@xxxxxxxxxx>
*Sent: *Wednesday, July 22, 2020 10:33
*To: *jakartaee-platform developer discussions <mailto:jakartaee-platform-dev@xxxxxxxxxxx>; JakartaEE Spec Project Leadership discussions <mailto:jakartaee-spec-project-leads@xxxxxxxxxxx> *Cc: *Jakarta specification committee <> *Subject: *Re: [jakartaee-platform-dev][jakartaee-spec-project-leads]Automatic Module Names in Jakarta EE 9

On 22/07/2020 01:51, Werner Keil wrote:

 > 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.

Servlet doesn't use it because I hadn't got to looking at the JPMS name

(I've only just finished cleaning up the Servlet spec doc). POM clean-up

(including JPMS name) was next on my TODO list.

Given a completely free choice I prefer the names without ".api" on the end.

However, the current versioning policy [1] uses api consistently for all

API related artefacts: JAR names, Maven co-ordinates and OSGi

Bundle-SymbolicName. Given that, it seems inconsistent not to use it for

JPMS names. Hence my proposal from January [2]:

"Take the OSGi Bundle-SymbolicName, replace any "-" with "." and use the

result as the JPMS name.". In terms of [1] this would be:


I understand from Kevin that there was pushback on the Platform call to

including ".api" as it was superfluous. I agree it is superfluous but

come back to the fact that [1] uses api for all API related artefacts.

In terms of [1], a possible JPMS name that doesn't include "api" is:


I don't think this decision has to open a can of worms. We already have

agreed, consistent naming for OSGi. Extending [1] to include JPMS names

looks to be a small, logical step. I think there are two clear options:



Given a free choice, I would prefer B. Given the naming conventions we

have in place, I think A is a better choice for consistency reasons. I

could live happily with either.

Unless we are too far down the Jakarta EE 9 release process to implement

a JPMS naming policy I think there are benefits to picking one of A or B

and applying it sooner rather than later.

If we are too far down the Jakarta EE 9 release process to implement a

JPMS naming policy now then Kevin's proposal below looks reasonable to

me with one additional point that any name currently using "java..."

must be changed to use "jakarta..."







 > Werner




 > Sent from Mail <> for

 > Windows 10




 > *From: *Scott Stark <mailto:starksm64@xxxxxxxxx>

 > *Sent: *Tuesday, July 21, 2020 23:47

 > *To: *JakartaEE Spec Project Leadership discussions

 > <mailto:jakartaee-spec-project-leads@xxxxxxxxxxx>

 > *Cc: *jakartaee-platform developer discussions

 > <mailto:jakartaee-platform-dev@xxxxxxxxxxx>

 > *Subject: *Re: [jakartaee-platform-dev]

 > [jakartaee-spec-project-leads]Automatic Module Names in Jakarta EE 9




 > 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 Tue, Jul 21, 2020 at 3:40 PM Kevin Sutter <sutter@xxxxxxxxxx

 > <mailto:sutter@xxxxxxxxxx>> wrote:


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



 >     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.



 >     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.



 >     Just for reference, we have also avoided the Module Naming

 >     convention in our official Jakarta EE Naming Conventions:



 >     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 <mailto:sutter@xxxxxxxxxx>     Twitter:

 >  @kwsutter

 > phone: tl-553-3620 (office), 507-253-3620 (office)

 > LinkedIn:

 > _______________________________________________

 > jakartaee-spec-project-leads mailing list

 > jakartaee-spec-project-leads@xxxxxxxxxxx

 > <mailto:jakartaee-spec-project-leads@xxxxxxxxxxx>

 > To unsubscribe from this list, visit






 > _______________________________________________

 > jakartaee-platform-dev mailing list

 > jakartaee-platform-dev@xxxxxxxxxxx

> To unsubscribe from this list, visit



jakartaee-platform-dev mailing list


To unsubscribe from this list, visit

jakartaee-platform-dev mailing list
To unsubscribe from this list, visit

Back to the top