Agree, Scott.
It
doesn't have to be final. But, it does have to be accessible
via
some open-source repo (milestone driver, rc driver, some type of
defined
driver).
---------------------------------------------------
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:
Scott
Stark <sstark@xxxxxxxxxx>
To:
Jakarta
specification committee
<jakarta.ee-spec.committee@xxxxxxxxxxx>
Cc:
Kevin
Sutter <sutter@xxxxxxxxxx>
Date:
06/05/2019
10:34 AM
Subject:
[EXTERNAL]
Re: [jakarta.ee-spec.committee] Compromise for approval of
Jakarta EE 8
specification projects
I don’t agree that a final release
of
a compatible implementation should be required for a spec to be
approved.
The point of at least one compatible implementation is to
validate that
the spec can be implemented. All of the window dressing of a
final release
has nothing to do with implementation details.
On Jun 4, 2019, at 6:30 PM, mdenicola@xxxxxxxxxxxwrote:
Personally
I think a final release should be required, but it's a good
discussion
topic.
MikeD
From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
On Behalf Of Bill Shannon
Sent: Tuesday, June 04, 2019 3:45 PM
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>;
Kevin Sutter <sutter@xxxxxxxxxx>
Subject: 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
_______________________________________________
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
