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.
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.> 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?
--
Mike Milinkovich
mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx
(m) +1.613.220.3223
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales
with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth,
Hampshire PO6
3AU
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
