|Re: [jakartaee-platform-dev] [jakarta.ee-spec] [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 https://github.com/eclipse-ee4j/servlet-api/tree/master/spec and https://github.com/eclipse-ee4j/servlet-api/tree/master/api 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.*".
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!
Back to the top