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

Hi,

 

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

 

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.

 

Werner

 

From: Mark Thomas
Sent: Wednesday, July 22, 2020 10:33
To: jakartaee-platform developer discussions; JakartaEE Spec Project Leadership discussions
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:

 

${API_PACKAGE}.api

 

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:

 

${API_PACKAGE}

 

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:

 

A: ${API_PACKAGE}.api

B: ${API_PACKAGE}

 

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

 

Mark

 

 

[1] https://wiki.eclipse.org/JakartaEE_Maven_Versioning_Rules

[2] https://www.eclipse.org/lists/servlet-dev/msg00233.html

>

>  

>

> Werner

>

>  

>

> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> 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:

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

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

> To unsubscribe from this list, visit

> https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads

>

>  

>

>

> _______________________________________________

> 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

 


Back to the top