| Re: [ee4j-community] Some guidelines for Maintenance Releases (MRs) of Java EE |
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. Re: Some guidelines for Maintenance Releases (MRs) of Java EE
8 Specifications (Werner Keil)
2. Re: Some guidelines for Maintenance Releases (MRs) of Java EE
8 Specifications (Bill Shannon)
------------------------------------------------------------ ----------
Message: 1
Date: Mon, 8 Jan 2018 22:40:08 +0100
From: Werner Keil <werner.keil@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Some guidelines for Maintenance Releases
(MRs) of Java EE 8 Specifications
Message-ID:
<CAAGawe3VCYbctNgyJJ1LnQLaH+LcOp3YUV06-iEBdgevb+39yQ@mail. >gmail.com
Content-Type: text/plain; charset="utf-8"
Will,
Thanks for the update.
Can you tell us what this means for backward-compatibility and ease of
adoption?
> Oracle does not recommend or support use the JCP process for any future
Java EE 8 functional enhancements.
effectively means it does not support the use of the javax.* namespace
either.
What does that mean for JSON-B (Yasson 1.1 still claims to implement JSR
367 without change) or more drastically EclipseLink 3.x?
https://projects.eclipse.org/projects/rt.eclipselink/ releases/3.0.0
There are 3 quarterly releases planned for EclipseLink 3. At least 3.0.0
as Major release (API breakage)
What does that mean for JPA? The relatively small MR of JPA 2.2 would not
offer Full Java SE 9 compatibility for EclipseLink 3 without an API
upgrade likely also something like JPA 3 or at least something that
declares full Java SE 9 modules.
Where is this supposed to happen and under what package name,
javax.persistence or something else?
This is just one example, but also a JSR (338) I served in its EG and
customers use quite a bit, so they are equally concerned about its future.
Thanks,
Werner
On Mon, Jan 8, 2018 at 6:00 PM, <ee4j-community-request@eclipse.org > wrote:
> 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
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j- >community/attachments/ 20180108/f83681aa/attachment. html
------------------------------
Message: 2
Date: Mon, 8 Jan 2018 13:56:30 -0800
From: Bill Shannon <bill.shannon@xxxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>, Werner
Keil <werner.keil@xxxxxxxxx>
Subject: Re: [ee4j-community] Some guidelines for Maintenance Releases
(MRs) of Java EE 8 Specifications
Message-ID: <b6e5da18-f55c-4583-671b-f6b105a8eefb@xxxxxxxxxx >
Content-Type: text/plain; charset="utf-8"
Werner Keil wrote on 01/ 8/18 01:40 PM:
> Will,
>
> Thanks for the update.
>
> Can you tell us what this means for backward-compatibility and ease of adoption?
>
> >? ?Oracle?does not?recommend or support use the JCP process for any future
> Java EE 8?functional enhancements.
> effectively means it does not support the use of the javax.* namespace either.
No, that's not what it means.? Please see the EE4J FAQ
<https://www.eclipse.org/ee4j/faq.php#packages >.
> What does that mean for JSON-B (Yasson 1.1 still claims to implement JSR 367
> without change) or more drastically EclipseLink
> 3.x??https://projects.eclipse.org/projects/rt.eclipselink/ releases/3.0.0
>
> There are 3 quarterly releases planned for EclipseLink 3. At least 3.0.0 as?
> Major release (API breakage)?
> What does that mean for JPA? The relatively small MR of JPA 2.2 would not
> offer? Full Java SE 9 compatibility?for EclipseLink 3 without an API upgrade
> likely also something like JPA 3 or at least something that declares full Java
> SE 9 modules.?
> Where is this supposed to happen and under what package name,
> javax.persistence or something else?
Functional enhancements of these APIs should occur as part of the EE4J project,
using whatever process is defined there.? Again, see the EE4J FAQ
<https://www.eclipse.org/ee4j/faq.php#jcp >.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j- >community/attachments/ 20180108/396e0f2c/attachment. html
------------------------------
_______________________________________________
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 6
********************************************