Lance, Since JTA 2.0
will only contain the jakarta.transaction package (not the java.transaction.xa
package), then I'm not clear on why changing this the Automatic Module
Name to "jakarta.transaction" would cause any breakage. Or,
I should say any more breakage than the package renaming is already causing...
I mean even if we leave this module name as java.transaction, the
contained API will have changed to use the jakarta.transaction package
name, so the app is already making changes to accommodate. And, if
the application requires both modules, then they could specify both java.transaction
and jakarta.transaction as dependencies.
What am I missing?
--------------------------------------------------- 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
Andersen <LANCE.ANDERSEN@xxxxxxxxxx> To:
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx> Cc:
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx> Date:
Re: [jakartaee-platform-dev] [jakarta.ee-spec][jakartaee-spec-project-leads]Automatic
Module Names inJakarta EE 9 Sent
I would leave the Jakarta Transactions
automatic module name as java.transaction at least for now. Changing
this could potentially break existing apps that are relying on this name
since I added it to the JTA 1.3 spec.
Certainly changing the module name going
forward is an option, but given this module will be used along with java.transaction.xa
module I would hold off for a bit to think this through in detail.
Werner, I agree that there are several options outlined in the document that Scott
started: https://docs.google.com/document/d/1LAAHKPJyREky9fEKv0xFd9IRDgXB58It53ryfyrNPtg/edit# I would still like to get input from the various Specification Projects
that are affected. Even if an "executive decision" has
to be made, I'd like to do with proper and full input. At the Spec Committee call today, the discussion centered around doing
minimal work for Jakarta EE 9. Option F in the above referenced doc
seems to be closest to that desire. But, Option E is also very close
with not much difference in effort. (I created Option E because the
Option D in the doc didn't match the description of Option D in this note
string. I just wanted to be very clear on the intent.) So, please, if you have an existing Automatic Module Name defined or an
explicit module-info.class file defined, read through the options in the
reference doc and provide feedback. Thanks!
There is more than
just placing them, but I said we should not bother to "specify"
anything in Jakarta EE because that has been done for us on the JDK level.
are almost more options than people to vote on it seems in the document
Scott started. Who will vote on those,
the members of the Spec Committee or someone else?
The specs that created
explicit module-info definitions should not be deprived because it may
turn application developers away from Jakarta EE, similar if the modules
kept changing multiple times after what we presented as "Big Bang"
where everything is renamed. "Yet another Big
Bang" in Jakarta EE 9.1 or 10 would send a bad signal even if it was
just for the module names.
Are the module names
we define seen as useful for application developers at this point? I
see how they are useful for Jetty's ability to run on the module path.
But my understanding is that applications are still loaded outside
of a module layer. At least until something like https://github.com/eclipse/jetty.project/issues/2895is
Werner seems to suggest
you can simply place all your application modules along with your spec
and platform impl modules on the module path and it all "just works".
In my experience it has never "just worked" from an application
perspective without much more thought and time to implement it correctly.
I do appreciate that
platform implementers want a consistent module name for their own needs
at this time. But as of now I see that as an issue for the implementers
and not necessarily for the application developers at larger. At
least until the Jakarta specification defines how modular applications
are loaded. I do believe that scenario will have different rules
than how the platform defines applications are loaded today, for example
how WARs are loaded at runtime.
In the end I do not
want to push for the absolute removal of all module names. I never
suggested removing existing module-info definitions. I certainly
didn't intend to trample on past legacies. But to insist that these
names have to be defined now and absolutely can never change in the future
when we don't fully understand how a JPMS defined Jakarta application would
look and load at runtime seems premature.
Eclipse Jetty 10 on
Jakarta EE 8 uses JPMS just fine. (we had to modify and release our own
jakarta jars because Jakarta EE didn't) Eclipse Jetty 11 on
Jakarta EE 9 uses JPMS as well. (we had to modify and release our own jakarta
jars because Jakarta EE didn't)
We have active users
on both, today.
Of course, our usage
is far more limited than the whole of Jakarta EE. (Only really servlet,
jsp, websocket with related tech)
But this failure to
address this is causing something in the wider community that hasn't been
brought up yet.
Projects that need
the JPMS naming and would rather "do it themselves" by modifying
the released jakarta jars with module-info and releasing them on maven
central under new coordinate spaces. Now we have broken
dependency conflict resolution on the global central repository system.
Do we really want that?
On Wed, Jul 22, 2020
at 10:14 AM Werner Keil <werner.keil@xxxxxxx>
wrote: 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.
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.
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.
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.