It seems fine to leave that out for now, we agreed that Implicit automatic module names (no descriptor) are ok for this release, but where automatic-module-name or a full module-info was already declared, they should be in the correct namespace, e.g. "jakarta.servlet" instead of "java.servlet". Plus it’s an absolute no-go IMO to call it "jakarta.servlet" now and suddenly switch to "jakarta.servlet.api" in the next release. If a component really had ".api" then it should stick to it while it’s part of the platform. JSP only added this recently, there was no automatic-module-name in Java EE 8 and it seems not before 3.x yet either. Looks like Mark Thomas added it just 3 weeks ago, probably not coordinated with other specs like Servlet. Werner When using modules I agree, but I don't see that we are willing to spend the time to come up with the final name that will be needed when JPMS is actually supported. Personally, I believe it does matter as you do not want to keep changing the module names especially if you are adding the Automatic-Module-Name Manifest Attribute.
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. 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)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen@xxxxxxxxxx
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec |
