Do we know which Specs. or API definitions need to change for
Option F?
Just a quick
follow-up.
In the referenced google doc, we're leaning towards Option F as
the
answer for Jakarta EE 9:
https://docs.google.com/document/d/1LAAHKPJyREky9fEKv0xFd9IRDgXB58It53ryfyrNPtg/edit#heading=h.98ncyfi7x77e
If this approaches causes extreme discomfort with any of the
Specification
Projects, please speak up. Thank you!
---------------------------------------------------
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
From:
Anthony
Vanelverdinghe <dev@xxxxxxxxxxx>
To:
Werner
Keil <werner.keil@xxxxxxx>, jakartaee-platform developer
discussions
<jakartaee-platform-dev@xxxxxxxxxxx>
Cc:
Kevin
Sutter <sutter@xxxxxxxxxx>
Date:
07/24/2020
06:39
Subject:
[EXTERNAL]
Re:
[jakartaee-platform-dev][jakarta.ee-spec.committee][jakarta.ee-spec][jakartaee-spec-project-leads]AutomaticModuleNamesinJakartaEE9
Hi Werner
The purpose of `Automatic-Module-Name` is to allow top-down
migration to
modules, i.e. fix the module name ahead of proper modularization
such that
other projects can reliably refer to it. So yes, I agree that
changing
it afterwards defeats the purpose.
However, I believe the disclaimer is justified in this case,
since I read
it as: "Some component specs have already defined module names.
However,
those names were never endorsed by the platform and are
inconsistent with
one another. In a future version of the platform, a naming
convention will
be established, and any existing module names will be updated to
comply
with it."
So as I see it, some specs made a promise about their module
name, even
though they weren't entitled to do so (though I understand they
did so
out of necessity). So it's the platform's right to update the
module name
if needed.
Kind regards,
Anthony
On 23/07/2020 23:56, Werner Keil
wrote:
Anthony,
Spring
is Pretty clear on "stable language-level modules”
https://docs.spring.io/spring/docs/current/spring-framework-reference/overview.html
and
it isn’t even an official standard, just popular, so for an
actual standard
we should regard that kind of stability even higher.
What
I would envision for the spec is not much more than the few
sentences in
the Spring docu.
I
see no problem with the top-most package, in fact it would
even work for
Websocket where the groupId is used by https://github.com/eclipse-ee4j/websocket-api/tree/master/api/server/src/main/java/jakarta/websocket/serverand client.
Some
like Authorization only changed the "javax.* " to "jakarta.security.jacc",
if they wold do the same for the automatic-module-name, then
why not.
If
a future version went to change that, sure why shouldn’t a
module change
but in general the modules should aim to be stable until they
get broken
down into smaller modules, e.g. CDI or it was discussed with
JPA whether
or not a "Light" module could be used by NoSQL.
Then
it could be justified to change that, but not just for the
sake of changing
so soon after the "Big Bang".
Werner
From:
Anthony
Vanelverdinghe
Sent: Thursday, July 23, 2020 23:42
To: jakartaee-platform
developer discussions;
Werner
Keil; Kevin
Sutter
Cc: Jakarta
specification committee
Subject: Re:
[jakartaee-platform-dev][jakarta.ee-spec.committee][jakarta.ee-spec][jakartaee-spec-project-leads]AutomaticModuleNamesinJakartaEE9
The listed specs all define the
module
name I'd expect them to have (assuming that `java.servlet` will
be changed
to `jakarta.servlet` for Jakarta EE 9), so I don't foresee
further changes
for them.
W.r.t. dependent projects, I doubt that many of them actually
depend on
the module name (e.g. in my experience, Spring Boot apps run
with everything
on the classpath). Either way, changing the module name would be
much less
disruptive than the current package name changes.
For Java modules, the typical naming convention is to use the
root package
(also see [1]).
[1] https://github.com/eclipse-ee4j/jakartaee-platform/issues/174
Kind regards,
Anthony
On
23/07/2020 22:27, Werner Keil wrote:
IMO
The
"existence" of modules may change, but frankly speaking
especially
for the Top 5 Jakarta EE 8 specs with modules
changing
the name of either of them would be extremely bad for the image
and adoption
of Jakarta EE.
We
spent a lot of time on "namespaces" or naming conventions,
therefore
those that already have modules better not drop them or
suddenly change
them if up to 1000 projects including heavyweights like Spring
Boot include
them, and that way Ten if not Hundreds of Thousands of apps
and services
may depend on those names.
Writing
a few sentences like the module name where present shall
reflect the Maven
groupId (except for EL or JSP all others do, Websocket is the
only special
case because it has a Client and Server module) or if everyone
thought
that would be better the artifactId (in such case every module
shall NOW
end with ".api” and not change between Jakarta EE 9 and 9.1 or
10)
is really no effort compared to the hours we already spent on
XML schema
that many specs have absolutely no use for.
Werner
From:
Anthony
Vanelverdinghe
Sent: Thursday, July 23, 2020 21:48
To: jakartaee-platform
developer discussions;
Kevin
Sutter
Cc: Jakarta
specification committee
Subject: Re:
[jakartaee-platform-dev][jakarta.ee-spec.committee][jakarta.ee-spec][jakartaee-spec-project-leads]AutomaticModuleNamesinJakartaEE
9
To me, this is essential:
(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.)
And with such a disclaimer in place, it doesn't really matter
which option
is chosen, even "do as you wish" would work (of the defined
ones,
I'd go with F though).
Also, Jakarta EE 9.1 should solely be about Jakarta EE on Java
SE 11 *on
the classpath* (i.e. the modulepath only contains the Java SE
modules;
anything else is on the classpath), so module names would
still not matter.
As I see it, bringing Java modules into the platform is a vast
topic, and
is thus unrealistic to do in Jakarta EE 9.1.
PS: since JPMS still seems pretty
popular
in conversations about Java modules: https://twitter.com/mreinhold/status/994669659029999616
Kind regards,
Anthony
On
23/07/2020 19:56, Kevin Sutter wrote:
I
can still appreciate Tibor's statements though -- we need to
quit adding
work, no matter how small of an effort, if we want to meet our
goals of
delivering Jakarta EE 9 this fall. Thanks, Tibor.
---------------------------------------------------
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
From: Werner
Keil <werner.keil@xxxxxxx>
To: jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date: 07/23/2020
11:47
Subject: [EXTERNAL]
Re: [jakartaee-platform-dev]
[jakarta.ee-spec.committee][jakarta.ee-spec][jakartaee-spec-project-leads]AutomaticModuleNamesinJakartaEE
9
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
That’s
not correct, because whereever the definitions of modules like
" java.servlet",
"java.json", etc. existed in Jakarta EE 8 this must also be
changed
just like the packages.
See
https://docs.google.com/spreadsheets/d/1g8jYG0JixO3wzZkpeyU1LMIQRhbnZ76kGtdMFE8mieE/edit?usp=sharing
Maybe
Scott was a bit ahead of himself sending it to ALL project
leads, but especially
those that already had a module declaration in Jakarta EE 8
and have not
changed that to "jakarta.*" must also do that.
Those
with a wrong automatic module name could also be "lazy" and
simply
remove that, I don’t think any full module-info wasn’t changed
or newly
introduced correctly, and especially those must not be
destroyed because
many of them like Activation are used in other specs like
Mail, so IMO
we could throw those options at them if that is what Scott
suggested, but
not sure, if the project leads may vote or if they should
simply apply
them, Option F is the preferred one by the Spec Committee and
also what
I mentioned here.
Only
8 specs would have to do anything, of these at least 4 already
had modules
defined in Jakarta EE 8, so they should leave them under the
new namespace,
the others could also just remove the automatic declaration.
Werner
From:
Tibor
Digana
Sent: Thursday, July 23, 2020 18:00
To: jakartaee-platform
developer discussions
Cc: Jakarta
specification committee
Subject: Re: [jakartaee-platform-dev]
[jakarta.ee-spec.committee][jakarta.ee-spec][jakartaee-spec-project-leads]AutomaticModuleNamesinJakartaEE
9
Our
goal was to change the license and rename the Java packages.
Please do
not prolong the work with more ambitions.
Dňa
št 23. 7. 2020, 16:48 Scott Stark <starksm64@xxxxxxxxx>
napísal(a):
I
sent an email to the project leads list asking for feedback in
the comments
section of the doc that I just added.
On
Thu, Jul 23, 2020 at 4:32 AM Werner Keil <werner.keil@xxxxxxx>
wrote:
Thanks
a lot, that might make it easier to decide.
Werner
Sent
from Mailfor
Windows 10
From:
Scott
Stark
Sent: Thursday, July 23, 2020 03:00
To: Jakarta
specification committee
Cc: jakartaee-platform
developer discussions
Subject: Re: [jakarta.ee-spec.committee]
[jakartaee-platform-dev][jakarta.ee-spec][jakartaee-spec-project-leads]AutomaticModuleNamesinJakarta
EE 9
Now
there are 6 options in the "Proposals
for Handling of Automatic-Module-Name header in Jakarta EE 9"
document after merging changes suggested by Kevin and Werner.
_______________________________________________
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
_______________________________________________
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