[
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
|
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/kevinwsutterFrom:
Werner
Keil <werner.keil@xxxxxxx>To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>, JakartaEE
Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>Cc:
Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>Date:
07/22/2020
07:13Subject:
[EXTERNAL]
Re: [jakartaee-platform-dev] [jakartaee-spec-project-leads]Automatic Module
Names in Jakarta EE 9Sent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
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%3E
>
*Sent: *Tuesday, July 21, 2020 23:47
>
*To: *JakartaEE Spec Project Leadership discussions
>
<mailto:jakartaee-spec-project-leads@xxxxxxxxxxx%3E
>
*Cc: *jakartaee-platform developer discussions
>
<mailto:jakartaee-platform-dev@xxxxxxxxxxx%3E
>
*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%3E%3Ewrote:
>
>
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%3E 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%3E
>
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
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev