| Re: [ee4j-community] Some guidelines for Maintenance Releases (MRs) of Java EE 8 Specifications |
Send ee4j-community mailing list submissions to
ee4j-community@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community
or, via email, send a message with subject or body 'help' to
ee4j-community-request@eclipse.org
You can reach the person managing the list at
ee4j-community-owner@eclipse.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ee4j-community digest..."
Today's Topics:
1. Some guidelines for Maintenance Releases (MRs) of Java EE 8
Specifications (will.lyons@xxxxxxxxxx)
2. Re: Devoxx EE4J BoF (Heiko Rupp)
------------------------------------------------------------ ----------
Message: 1
Date: Sun, 7 Jan 2018 17:25:13 -0500
From: will.lyons@xxxxxxxxxx
To: ee4j-community@xxxxxxxxxxx
Subject: [ee4j-community] Some guidelines for Maintenance Releases
(MRs) of Java EE 8 Specifications
Message-ID: <53cd3fe2-021d-981b-55f2-a23336884007@xxxxxxxxxx >
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hello -
Oracle continues to work with members of the Java EE community to
contribute GlassFish and Java EE 8 technologies to the Eclipse
Enterprise for Java (EE4J) project at the Eclipse Foundation. We
expect these technologies to evolve within EE4J, and we do not expect
there will be a ?Java EE 9? or a GlassFish Reference Implementation for
it. However, as stated previously in the EE4J FAQ
<https://www.eclipse.org/ee4j/faq.php >, Oracle may deliver maintenance
releases of GlassFish 5.0 and related Java EE 8 JSRs.
The first example of a Java EE 8 JSR Maintenance Release (MR) has
surfaced. Future releases of Java SE will require clearer demarcation
of those aspects of the Java Transaction API specification (JSR 907)
that are a) implemented in Java SE and b) implemented in Java EE
implementations. An MR of JSR 907 has been opened to provide this
clarification and demarcation, and is available at:
https://jcp.org/en/jsr/detail?id=907
No functional changes to the JTA specification are planned as part of
this MR. Oracle has proposed to use the JCP process to review this MR,
while the Eclipse Enterprise for Java (EE4J) specification process is
being defined. The use of the JCP process for this Java EE
specification is only intended for this maintenance purpose during this
interim period when the EE4J process is being defined. The Eclipse
Foundation will act as co-lead of the JTA specification with Oracle, and
Mark Little of Red Hat will serve in the role of co-spec lead, and
Oracle, Eclipse, and Red Hat have jointly agreed to represent the
interests of EE4J in leading this specification.
This MR raises a general question of when MRs for current Java EE 8
specifications is appropriate. We thought it would be useful to
establish and communicate guidelines for using the MR process for Java
EE 8 specifications.
Oracle recommends and supports the use of EE4J-driven processes for
functional enhancements to Java EE 8 specifications, and does not
recommend or support use the JCP process for any future Java EE 8
functional enhancements. However, from time to time there may be valid
reasons for providing MRs of Java EE 8 specifications.
Appropriate reasons for introducing MRs to current Java EE 8
Specifications are the following:
i) Fixing potential errata in specifications, in order to clarify or
correct the specifications to align with the original intent of the
specification.
ii) Addressing potential security vulnerabilities that may be
associated with current specifications.
iii) Enabling clearer demarcation of those aspects of Java EE
specifications that are implemented in Java SE and those that are
implemented in Java EE, as required to enable evolution of the Java SE
platform in a timely manner. The technologies currently shared by EE
and SE, and the plan to achieve clear demarcation, are publicly covered
in http://openjdk.java.net/jeps/320 . Any material changes to this JEP
will be shared directly with the EE4J PMC.
As Java EE Spec lead, Oracle will discourage the use of the JCP process
for MRs to Java EE 8 Specifications for any other reason than those
given above. The EE4J process should be used. If some additional
reason for a Java EE 8 MR is identified, Oracle will encourage that the
spec lead or expert group proposing the MR review the reason for the MR
with the EE4J Project Management Committee (PMC). The EE4J PMC will
determine if there is a valid reason for the MR and will update the list
above as appropriate.
We hope this note provides context for the JTA MR above and review of
other potential MRs going forward. Thanks very much.
Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j- >community/attachments/ 20180107/eeef87c7/attachment. html
------------------------------
Message: 2
Date: Mon, 08 Jan 2018 08:52:45 +0100
From: "Heiko Rupp" <hrupp@xxxxxxxxxx>
To: spousty@xxxxxxxxxx, "EE4J community discussions"
<ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Devoxx EE4J BoF
Message-ID: <84E848A4-E597-4CF2-A8BB-A41FF3A5A1C7@xxxxxxxxxx >
On 5 Jan 2018, at 19:20, Steven Pousty wrote:
> I put in for Devoxx FR - if I get my talk I can certainly help in the BOF.
> I can probably also get some other Red Hatters as well
I have submitted a talk to DevoxxFR and if that is accepted,
I may be able to chime in as well. My French is rusty, but
I would certainly be there.
------------------------------
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community
End of ee4j-community Digest, Vol 5, Issue 5
********************************************