[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-platform-dev] [jakarta.ee-spec][jakartaee-spec-project-leads]Automatic Module Names inJakarta EE 9
|
Werner,I agree with the
stand that any module-info.class material that existed prior to Jakarta
EE 9 can stay. These items were introduced in Java EE 8, moved to
Jakarta EE 8, and are now part of Jakarta EE 9. We're not going to
remove them at this point. That would make no sense. But, we
do not want new module-info.class files to be introduced in Jakarta EE
9. And, the existing module-info.class files have to realize that
they might have to change once the proper naming conventions are defined
for Java SE 11.
---------------------------------------------------
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>Date:
07/22/2020
10:22Subject:
[EXTERNAL]
Re: [jakartaee-platform-dev] [jakarta.ee-spec][jakartaee-spec-project-leads]Automatic
Module Names inJakarta EE 9Sent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
I
also leave that to Dmitry to share his thoughts, but sorry
"If
you have a module-info.class remove it"
seems totally unacceptable to me.
There
is work that went into those and where a spec comes with SPIs these all
need to be in a properly defined module-info.
I
won’t use bigger ones for simplicity, but even one of the last files Bill
Shannon ever created in March:
module
jakarta.activation
{ | |
|
exports jakarta.activation; |
|
requires java.logging; |
| } |
Highlights,
it is not just the module name, it also defines, which JDK modules are
required to run this, and I would not destroy that, needless to say, we’d
trample on Bill’s legacy if JAF was forced to remove that file.
Werner
From:
Werner
Keil
Sent: Wednesday, July 22, 2020 17:14
To: jakartaee-platform
developer discussions
Subject: Re: [jakartaee-platform-dev][jakarta.ee-spec][jakartaee-spec-project-leads]Automatic
Module Names inJakarta EE 9
There
is, it’s called JPMS and once you have a module declaration (both explitic
or automatic) in the module-path this works, the behavior is specified
by the Java SE platform and I see no reason why we would have to do anything
in Jakata EE on that.
As
long as those specs that did a great Job in properly declaring module-info
are not forced to destroy that (including Services and lots of other stuff)
and rip it out only to put it back in again, I guess I could live with
removing the automatic-module-name from the POM because that is a lot less
work and could even be commented out for now.
However,
there shall be no renaming later, so if it’s called "jakarta.activation"
or "jakarta.json" in a proper module-info, then it must not change.
Especially
those two are fairly independent and used not just by Jakarta EE components
or different specs, they are used by other types of applications including
Maven plugins etc. or by the Spring stack and there automatic-module-name
is also what every Spring JAR I saw lately does, therefore we’d lose an
advantage compared to Spring if we removed the automatic-module-name now,
but it would help clean the mess that so far only exists in those automatic
module names.
Werner
From:
Thomas
Watson
Sent: Wednesday, July 22, 2020 16:54
To: jakartaee-platform-dev@xxxxxxxxxxx
Subject: Re: [jakartaee-platform-dev] [jakarta.ee-spec][jakartaee-spec-project-leads]Automatic
Module Names in Jakarta EE 9
How
are we intending developers to use the module names that get specified
by the spec JARs? I have not seen any indication that there is a
standards based way to build a Jakarta EE application out of JPMS modules.
Furthermore there is no specified behavior for how a Jakarta EE platform
implementation would load such an application as modules at runtime. Any
such support will have to be implementation specific and that implementation
likely will need to have a coherent set of modules it provides to implement
the platform out of modules. Any such application will likely need
to target that specific implementation until there is a standard way of
doing this. If Jakarta ever decides modules have to be supported
at runtime I am sure it will likely look different from any decisions we
try to make today for module names.
For
this reason I agree with Scott that it probably does more good to remove
the Automatic-Module-Name headers from all specification JARs.
Tom
-----
Original message -----
From: Scott Stark <starksm64@xxxxxxxxx>
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
To: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Cc: JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>,
jakartaee-platform-dev-bounces@xxxxxxxxxxx, jakartaee-platform developer
discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] [jakarta.ee-spec] [jakartaee-spec-project-leads]Automatic
Module Names in Jakarta EE 9
Date: Wed, Jul 22, 2020 9:48 AM
Then
that is heading in the direction of the non-stated option D to remove all
Automatic-Modue-Name headers. Doing no work around this issue for Jakarta
EE 9 leaves the headers in a bit of a mess. It would seem that the simplest
change timewise would be to mandate their removal. I think we need
to draft a voting resolution on 4 different options with the pros and cons
of each and decide which route to take. I'll create a draft for comments.
On
Wed, Jul 22, 2020 at 9:37 AM Lance Andersen <lance.andersen@xxxxxxxxxx>
wrote:
Hi
Kevin,
On
Jul 22, 2020, at 10:12 AM, Kevin Sutter <sutter@xxxxxxxxxx>
wrote:
Agree,
Lance. That's why I don't want to push this into the Jakarta EE 9
schedule. We may come up with what we think is the right answer,
but until we really dive into the JPMS impact across the Jakarta EE board,
we'll probably have to make changes later. I would prefer to leave
things as-is for Jakarta EE 9 -- except for maybe the four items we have
identified as getting rid of the 'java' prefix.
This
is why we held off adding automatic module names prior to the transition
to Eclipse as we felt after some lengthy internal discussions that this
should only be done once and given the transition, it was best to wait.
Scott,
I would not add the manifest element without finalizing on a name. The
intent of this element was to ease the transition to the module world,
but if the name is not going to be firmed up, i would wait as it adds not
value and just causes extra churn to the developers.
Best
Lance
_______________________________________________
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