I'm just trying to keep the two issues separate so we can make
more progress on the important issue for this group, which is to
define a process to replace the JCP.
If you think the spec process needs to say something
about modules, we could talk about that.
Or if you think the spec process needs to say something about
how specs express requirements of any kind, then we should talk
about that.
For example, we could consider whether the spec process
document would follow RFC 2119, and
whether it would require all specs approved through the process
to follow RFC 2119.
Or we could talk about whether specs created through the process
would be permitted to allow implementations to claim 98%
compatibility with the spec, or whether they must treat
compatibility as binary.
How much should the spec process dictate about how specs
are written, what they're permitted to allow, what requirements
they must have, etc.?
These would be good things to discuss in this group right now, and
maybe that's what you intended.
Whether Jakarta EE should require support for modules is a
discussion we should leave until later, and probably a different
group.
Kevin Sutter wrote on 05/10/2018
11:55 AM:
> Shouldn't
this be a discussion we have in the Jakarta EE "platform
expert group"? This seems to have nothing to do with creating
a specification process to replace the JCP.
Sure, Bill. But, the
requirement for JPMS modules was originally listed in Mike's
spec requirements document. So, that started the discussion.
We don't have to finish it right now, but we do need to get
to a common understanding of what type of wording will be in
the spec requirements.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail: sutter@xxxxxxxxxx
Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Bill Shannon <bill.shannon@xxxxxxxxxx>
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>,
Ian Robinson <ian_robinson@xxxxxxxxxx>,
Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>
Cc: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
Date: 05/10/2018 01:25 PM
Subject:
Re:
[jakarta.ee-spec.committee] Modules [Was Re: Requirements
Document]
Sent by:
jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
An ecosystem of vendor implementations of Jakarta
EE 9 with no support at all for JPMS modules seems like
failure to me. If it's not a requirement, that seems like a
likely outcome.
I agree with not requiring applications to use
modules.
I agree with not requiring application servers
to be built out of modules.
I don't agree with application servers not
being required to support applications that want to use
modules. Obviously this would be a significant addition to
the spec, but it's one that I think the community will
expect.
And I especially don't agree that a Jakarta EE
Micro Profile implementation should not be required to be
delivered as modules.
But back to my meta-point...
Shouldn't this be a discussion we have in the
Jakarta EE "platform expert group"? This seems to have
nothing to do with creating a specification process to
replace the JCP.
Ian Robinson wrote on 05/10/2018 08:09 AM:
Almost.
I would not want to see applications or implementations of
the Jakarta EE platform technologies to be required to
run as JPMS modules (including CTS itself). The degree to
which future editions of JakartaEE will need to be
JPMS-enabled is a topic for discussion but so long as there
is no requirement for JPMS as part of compliance I think
we'll be fine.
Regards,
Ian
Ian Robinson, IBM Distinguished Engineer
WebSphere Foundation Chief Architect
IBM Hursley, UK
irobins@xxxxxxxxxx
Admin Assistant: Janet Brooks - jsbrooks12@xxxxxxxxxx
From: Mike
Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>
To: Ian
Robinson <ian_robinson@xxxxxxxxxx>, Jakarta specification committee
<jakarta.ee-spec.committee@xxxxxxxxxxx>
Cc: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
Date: 10/05/2018
14:26
Subject: Re:
[jakarta.ee-spec.committee] Modules [Was Re: Requirements
Document]
On 2018-05-10 5:35 AM, Ian Robinson wrote:
The first LTS release of Java SE that will contain modules is
Java 11 so future versions of Jakarta EE (after EE8) will need
to have an opinion on Modules and some specificity around
module definitions for Jakarta EE technologies. Beyond that I
would expect the use of JPMS for Jakarta EE technologies to be
well defined but optional. Obviously that will be a decision
for the community but I would not expect JPMS to be a
requirement enforced by future Jakarta EE TCKs.
Ian, I think what you're saying is that a
future version of Jakarta EE will need to JPMS-enabled, but
not require that applications built upon it use JPMS. Do I
understand that correctly?