| Re: [jakarta.ee-spec.committee] Compromise for approval of Jakarta EE 8 specification projects |
My understanding is that Eclipse 5.1 will be used as the Compatible Implementation of Jakarta EE 8.
I am aware that I may be totally mistaken in this belief as there is a level of shifting sands.
Steve
From:jakarta.ee-spec.committee-bounces@xxxxxxxxxxx <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
On Behalf Of Kevin Sutter
Sent: 05 June 2019 14:18
To: Bill Shannon <bill.shannon@xxxxxxxxxx>
Cc: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] Compromise for approval of
Jakarta EE 8 specification projects
Bill,
> It's
not our plan to hold up this release until other compatible implementations
are available. If you think we need to do that, you should bring
that up at the Steering Committee, although that would clearly blow our
schedule.
I've tried to be very clear that having additional Compatible Implementions
is a requirement for Jakarta EE 8. And, I don't think this blows
the schedule. I know that Eclipse Glassfish, Wildfly, and OpenLiberty
are all active with running the Jakarta EE TCK with varying results. We
should probably identify a milestone date on the schedule for CIs to be
100% TCK passing in order to be included with the announce. Since
this activity is independent of the release and being driven by the respective
open-source development communities and vendors, it should not affect the
schedule.
Also, both you and Mike D have indicated a final release should be required...
But, I don't know how we keep to the schedule if we have to produce
a new release of Glassfish (for example) that uses the updated APIs and
then do the final testing -- all of this before we submit for the Release
Review. This just doesn't work. I think we need to re-address
what is really required for a Compatible Implementation prior to the Release
Review.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta 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>,
Kevin Sutter <sutter@xxxxxxxxxx>
Date: 06/04/2019
04:54 PM
Subject: [EXTERNAL]
Re: [jakarta.ee-spec.committee] Compromise for approval of Jakarta EE 8
specification projects
Kevin Sutter wrote on 6/4/19 1:05 PM:
Hi Bill,
We're in a classic chicken-and-the-egg situation... It's difficult
to have any Compatible Implementation that uses the APIs that are being
submitted for review. We have this situation with every MicroProfile
release. We require a Compatible Implementation for the Release Review,
but it doesn't have to be a final GA product. It has to be an accessible
open-source project that demonstrates the functionality defined by the
Spec and API and it passes the defined TCK. But, it doesn't have
to be a final X.Y release.
At the JCP we required the implementation to be released as a "final"
product soon after the spec was approved. (It usually took hours
to weeks after the approval to release the implementation.) Allowing
some slop between the spec approval and the implementation release solved
the chicken-and-egg problem.
I guess we need to decide what we require for the JESP. I was assuming
it would be the same. I don't think it would be appropriate to approve
the spec with only a "day in the life" of an implementation that
may never be recreated. Perhaps a final release is not required,
but it seems like it should at least be some sort of distinguished milestone
release. Personally I think a final release should be required, but
it's a good discussion topic.
What is even more unique with this Jakarta EE 8 release is that we want
to make a big splash with this initial release. When we announce
Jakarta EE 8, we want to also announce that we have several Compatible
Implementations -- Eclipse Glassfish, OpenLiberty, and Wildfly (at least,
maybe there are others). So, how can we accomplish this when the
Specs, APIs, and even the TCKs are still going through the final Reviews?
It's not our plan to hold up this release until other compatible implementations
are available. If you think we need to do that, you should bring
that up at the Steering Committee, although that would clearly blow our
schedule.
If other implementations can finish in the same time as the existing schedule,
that would be great! Clearly the TCKs have to be "frozen"
at the start of the release review, so that gives other implementations
some time to ensure that they pass the TCKs. If they can show that
they pass the frozen-but-not-yet-approved TCKs at the end of the review
period, I think we should consider them compatible implementations as part
of the release. And of course if they pass the finalized TCKs shortly
after the approval, we should add them to the list of compatible implementations.
If other implementations are intending to be compatible at the current
release date, that would be helpful to know ASAP. That might require
additional resources to support usage of the Jakarta EE TCKs and we should
plan accordingly.
We do have to remember that the TCK is testing functionality, not whether
the proper license and/or javadocs have been updated.
We expect the Specification Committee to be checking that the submitted
javadocs include the correct license, spec name, etc. as part of the specification
approval process.
So, technically, once these CIs pass the TCK (with or without the updated
APIs), then they should be ready for the Release Review and the eventual
Announce.
Yes, other compatible implementations don't need to depend on these API
jar files.
But, I do get your point about having to test these updated APIs before
releasing them. I thought that was part of the TCK testing that Dmitry
and Ed were going over this morning?
Yes, it is. Every changed artifact needs to be tested before release.
Every API jar file will be updated and released. Some implementations
might also be updated and released.
During our PMC call just prior to the Steering Committee call, Dmitry explained
that the individual API TCKs would need to be executed to ensure they are
compliant. These individual tests would not be comprehensive though
-- we should still do some testing that they work throughout the whole
TCK bucket.
All of the existing EE4J implementations need to be tested with the new
Jakarta EE TCKs since those are the implementations that we will include
in the approval process as compatible implementations.
Maybe we need all of the Compliant Implementations to re-run the TCK with
the proper APIs during the Review period? Given that the individual
API TCKs were run prior to the review, and the CIs would already passed
the required TCKs (minus the API updates), maybe re-running the CIs with
the updated APIs would be sufficient at this time? Maybe this is
the gist of your compromise?
Yes, we just need to do something to ensure that the updated API jar files
still match the spec and no unexpected changes or errors have crept in.
Again, we're not expecting to include these updated API jar files
in most of the Compatible Implementations at EE4J for Jakarta EE 8, and
no other Compatible Implementation is required to use them (although they
can if they want to).
> We
need to update all of the javadocs for all of the APIs to use the new
specification names and to use the Eclipse Foundation Specification License.
Since we're actively discussing how far-reaching the acronym usage limitation
is, I'll leave the extent of the javadoc updates out of this discussion
and just focus on the requirements of the Release Review and the Compatible
Implementations.
Even ignoring the acronyms, most of the javadocs will include the name
of their own spec (which is changing), and many will include references
to JSRs (which need to be removed or replaced). The javadoc updates
may not be extensive, but they include at least the new license, and in
most cases will include some other required changes.
_______________________________________________
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://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee