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
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...
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.
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 Twitter: @kwsutter phone: tl-553-3620 (office), 507-253-3620 (office) LinkedIn: https://www.linkedin.com/in/kevinwsutter