Re: [jakarta.ee-spec.committee] Compromise for approval of Jakarta EE 8

["Kevin Sutter" <sutter@xxxxxxxxxx>]

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.

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?

We do have to
remember that the TCK is testing functionality, not whether the proper
license and/or javadocs have been updated.  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.

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?  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.

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?

>  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.

---------------------------------------------------
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

jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
wrote on 06/04/2019 01:13:12 PM:

> From: Bill Shannon <bill.shannon@xxxxxxxxxx>
> To: Jakarta specification committee
<jakarta.ee-spec.committee@xxxxxxxxxxx>
> Date: 06/04/2019 01:13 PM
> Subject: [EXTERNAL] [jakarta.ee-spec.committee]
Compromise for 
> approval of Jakarta EE 8 specification projects
> Sent by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
> 
> In order to complete Jakarta EE 8 as quickly as possible, we're proposing
> a compromise that is different than what we would normally do.  I'd
> like to make sure this compromise is acceptable to the Specification
> Committee so that there are no surprises when we are reviewing the
> Jakarta EE 8 specifications for approval.
> 
> Since Jakarta EE 8 will be completely compatible with Java EE 8, we've
> proposed that, in general, we will *not* be releasing new versions
of
> the implementations for each API.  We will simply test the existing,
> released, implementations that have already passed the Java EE 8 TCKs
> using the Jakarta EE 8 TCKs.  (In some cases projects may choose
to
> release new versions of the implementations, and while that will be
> allowed, it will neither be required nor expected.)
> 
> That would be simple enough except for one thing...
> 
> 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.
> This will require releasing new versions of (at least) the API jar
files
> for every API.  The corresponding javadocs will be included in
the release
> reviews for the specifications.
> 
> The specification release reviews will require the specification documents,
> which will include theses javadocs, the TCKs, and at least one compatible
> implementation.  Again, the compatible implementation will be
the existing,
> released, implementation that does *not* use these API jar files.
> 
> It would seem wrong to release these new API jar files without any
testing
> whatsoever.  We're proposing that these API jar files be tested
by (where
> applicable) integrating them with the corresponding standalone implementation
> and testing that combination with the corresponding standalone TCK,
and/or
> integrating that API jar file into GlassFish and using one of the
GlassFish
> TCK jobs to test that API jar file with its corresponding TCK tests.
 Note
> that these combinations of API jar files and implementations would
*not*, in
> general, be released (although a project could choose to do so as
long as it
> doesn't depend on GlassFish).
> 
> Ideally, the combination of API and implementation would be tested
and
> released, and that's what would be referenced as a Compatible Implementation
> for the specification release review.  But we won't do that for
this release.
> Given the constraints of this release, we believe the above compromise
is
> acceptable.
> 
> Comments?
> 
> _______________________________________________
> 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://urldefense.proofpoint.com/v2/url?
> u=https-3A__www.eclipse.org_mailman_listinfo_jakarta.ee-2Dspec.committee&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=ZeqDVZQccycJkrJxV_sZMqJObDwCJkj6sJn1pXfRdhY&s=zMzwgIM7lGGh8FyW4apXd6Ft8i3JfapMLoWTZWIQn88&e=
>