Re: [jakarta.ee-community] Any Plans for JPMS for Jakarta EE?
Jason,I am also having
a discussion about Jakarta EE 9.1 via this document: https://docs.google.com/document/d/1yFfD0ezjr1QFM3onGK76E3RhItN5FFEfhz12VA5wGYQ/edit#I have a short
section on JPMS Module Naming Conventions. We documented some "guidelines"
for EE 9. And, now I am asking if we should firm up these "guidelines"
for 9.1. Note that we are not proposing JPMS Modules for the implementations.
We are only attempting to define the Module Naming conventions for
the APIs. You are welcome to participate in the discussion in the
Google Doc. Thanks!
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)From:
EE community discussions <jakarta.ee-community@xxxxxxxxxxx>Date:
Re: [jakarta.ee-community] Any Plans for JPMS for Jakarta EE?Sent
Werner,Thank you very much
for your detailed response! I missed their session at JakartaONE, and I
am looking forward to watching the replays.I will check out
the presentation about JPMS and Spring Boot that you mentioned as well.Thanks again,Jason Pollard
<jakarta.ee-community-bounces@xxxxxxxxxxx> on behalf of Werner Keil
Sent: Tuesday, December 8, 2020 9:32 PM
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] Any Plans for JPMS for Jakarta
EE? Jason, I'm not sure if you attended all the
JakartaONE live sessions, because JPMS was mentioned quite a bit when I
spoke to Ivar before Ed's and Emily's presentation.We already looked at JPMS in great detail
for Jakarta EE 9, check out https://docs.google.com/spreadsheets/d/1g8jYG0JixO3wzZkpeyU1LMIQRhbnZ76kGtdMFE8mieE/edit?usp=sharingI was driving this in the Spec Committee especially for every spec that
already had a module declaration in Jakarta EE 8 or before.20 do, either via META-INF or a full
module-info. More than 2/3 of all relevant specs, because a few like the
"stable" ones are considered "legacy" and don't need
to bother doing this if they are frozen and not actively maintained any
more.Of the 10 at most that are missing, CDI
and Security, possibly Concurrency Utilities are the only pain points because
they are reused by others more than the rest, on the other hand an ongoing
discussion about a "CDI Lite" or "Core" module that
could hopefully be the foundation of the "Full CDI" shows, there
is room for improvement in CDI before declaring modules for it makes more
sense.With CDI not being truly modular yet,
you won't find MicroProfile using it a lot, while Spring and Spring Boot
do in most of the newer and well-maintained parts. Ed mentioned Spring Roo in their talk,
but there was also Spring Dynamic Modules using OSGi long before anybody
even dreamed of "Jigsaw". Jaap Coomans gave a good presentation
about JPMS with Spring Boot at Java Global Summit this year."There are profiles", well
there are two and they are both quite large and monolithic, even the Web
Profile. Thus if a "Micro Profile", "Service Profile"
or whatever you want to call it should be successful and not yet another
profile that's too big and not flexible enough, these profiles need some
kind of modularity, and the Java Platform exposes JPMS now, even if OSGi
may be superior, but it is a lot less used and maybe the "Betamax"
compared to "VHS" for those who still remember video tapes ;-)
On Wed, Dec 9, 2020 at 12:15 AM Jason
was wondering if there are any plans or discussion around JPMS for Jakarta
EE? Does it even make sense to use Java modules for Jakarta EE, since we
have profiles and many application servers are already small?
jakarta.ee-community mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community_______________________________________________
jakarta.ee-community mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community