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



jakarta.servlet is the groupId, but the problem of Jigsaw and Maven is, that they don’t usually correlate, e.g. the top level POM won’t define a JPMS module, there is neither a JAR nor META-INF, while the .api modules underneath do.


Are you suggesting that these should all use a postfix like ".api"?


Especially where this was explicitly declared in a "module-inf", some like Activation even by the late Bill Shannon, it never uses ".api", and while he may not have mentioned that in the naming conventions, he was one of the main creators of that convention.


Some like Activation have a weird Maven structure because the "activation" module contains the actual sources, but there is yet another "activaitonapi" module which does nothing but pack the sources from a different module or JAR into the final form.

Jakarta Faces also does a similar trick, so while most

contain both a and the parent POM has a name like "servlet-parent" (no Jigsaw module here) and the "servlet-spec" is also a POM artifact, so none of them can ever produce a Jigsaw module anyway.

Therefore the ".api" seems redundant and unnecessary because there is no case with more JAR module at least not under the API/Spec namespace.


JSON Processing also contains the implementation, but that is under the Glassfish umbrella and if it already did define a JPMS module, it’s "org.glassfish.*" and not "jakarta.*".




From: Scott Stark
Sent: Wednesday, July 22, 2020 15:35
To: Jakarta specification discussions
Cc: JakartaEE Spec Project Leadership discussions; jakartaee-platform developer discussions
Subject: Re: [] [jakartaee-platform-dev][jakartaee-spec-project-leads]Automatic Module Names in Jakarta EE 9


For the 9.0 release, I guess it does not matter too much, but the discussion around the name is going to get more involved I suspect, and expand beyond the scope of just an artifact name based module name. For example, to simplify the end user's life, I can see having one or more aggregate modules using the spec base (jakarta.servlet) that define the various import/export/services relationships for a typical servlet app, JSP app, JSF app, etc. With that structure I would expect that we do want .api modules for every spec.



On Wed, Jul 22, 2020 at 8:06 AM Kevin Sutter <sutter@xxxxxxxxxx> wrote:

Thanks for the input!

We'll have to leave this thread open for a bit to see if we are opening a can of worms or not... ;-)

Mark, thanks for volunteering to minimally change "java.servlet" to "jakarta.servlet".  If we get additional volunteering along these lines, then we could contain this minimal update for Jakarta EE 9 (authentication, authorization, servlet, and transactions).

Let's see how this discussion plays out (and get input from the Spec Committee) as to what's containable for Jakarta EE 9, or 9.1, or 10.  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)    


Back to the top