Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] Modules [Was Re: Requirements Document]


I unexpectedly have a free hour so I am going to try to take a stab at creating a revised requirements document that captures the conversation to date. It's gotten to the point that the comments are getting more distracting than helpful. I will also split out some of the roadmap discussion into a separate document, or at least a separate section of the document.

On 2018-05-10 4:45 PM, Bill Shannon wrote:

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?



Back to the top