My understanding was that most people wanted the "API" projects to
contain the API Java classes, the API specification document, and
the TCK for the API, each as separate repositories under that
project. If so, how does the Eclipse Development Process handle
releasing artifacts from each repository independently? Are they
just considered project releases that only produce one of the
project artifacts? Can there be multiple project plans active
simultaneously?
While "major" updates to API projects would likely synchronize
changes to all 3 repositories (along with the RI repository),
"minor" updates might not.
I assume coordination between API and RI projects is the
responsibility of the Project Leads for the two projects, if they're
not the same people.
Another thing to keep in mind is that the implementations for some
Jakarta EE specs are not "separate", they're part of GlassFish.
Coordinating updates to GlassFish with updates to all these other
artifacts is a non-trivial task. it's not just a matter of sweeping
all the piece parts into the same box and releasing it.
Steve Millidge (Payara) wrote on 05/
9/18 05:02 AM:
Reusing
as much of the EDP as possible is a good way forward for
developing the actual outputs that make up a spec.
I’ve
taken Wayne’s thoughts below and attempted to show them in a
straw man picture (attached) to illustrate the number of
projects involved and the process between them. Blue is in
EE4J and Brown is in Jakarta EE. Note the top 5 swim lanes
will be duplicated n times to make up a profile where n is
the number of specs in the profile. Note the added
complexity that some projects incorporated in a profile are
not in EE4J or developed at the Eclipse Foundation
😊
So
my understanding is that the individual EE4J project(s)
iterate the API, RI, TCK and Specification document to
create a release using the EDP? However it is likely that
the API, RI, TCK and spec are different Eclipse projects
under EE4J so some coordination between them is required to
create a candidate spec release. Is that managed within the
EE4J PMC or in Jakarta EE?
The
spec committee then ratifies the 4 outputs as an individual
spec using some process to be defined? Possibly a simple
vote within the spec committee?
A
missing step from below is incorporation of the individual
specification into a profile release. I would assume a
profile (in the profile spec) will impose some internal
consistency requirements on an individual spec before it is
admitted to a profile. I’ve not added this feedback loop to
the picture.
For
profile releases I would advocate a release train model
similar to what is currently done within the Microprofile
project. In that a profile “sweeps up” whichever relevant
individual specifications meet the profile requirements at
their point releases and then releases a profile. The
profile will very likely require an EE4J project for Profile
TCK, Profile RI and Profile Spec document. These outputs
will then require ratification via the spec committee?
Steve
From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
On Behalf Of Wayne Beaton
Sent: 08 May 2018 20:45
To: Jakarta specification committee
<jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] Jakarta EE 8
certification goal
I've added a few definitions to the
document. They may be wrong; I put them in there because I
get the feeling that my definition of what
Specification Project means is different from yours.
In
my email regarding goals, I started by defining what I
thought are three different aspects of this process.
In my mind, it was helpful to keep these separate.
-
The
development of the specifications themselves;
-
The
process of ratifying and promoting official
specifications; and
-
Certification
of implementations of ratified specifications.
One big difference between the JCP
and what we will do is, I believe, that we won't spin up
an entirely new JSR/team for each version of the
specification. In my mind, the Specification Project is
an open source project in the sense that it is defined
by the Eclipse Development Process (EDP). Team members
come and go, but the project itself persists. That
project is responsible for generating all releases of
the specification.
Development of the Specification
The general process that Eclipse open
source projects follows is this:
A project proposal defines a scope of
work that (generally) persists for the lifetime of the
project (the scope can be changed if there is good
reason to do so). Each release cycle starts with
planning. For some projects this planning is an informal
list of issues; other projects are more rigorous (we can
decide what level of rigour is required for a
Specification Project). Milestone builds give the
primary stakeholders an opportunity to review the work
and provide feedback. The final release is what is
delivered to the broad community.
The open source project team is
responsible for generating the artifacts associated with
the Specification as part of a release (as specified by
the Eclipse Development Process. I believe that this
minimally includes a document and API, along with
pointers to an official reference implementation and
TCK.
Concerns regarding IP flows
notwithstanding, I believe that the EDP almost competely
covers this part of the process. You can, for example,
think of the notion of milestone builds as early draft
releases in the JCP sense. We can decide how or if the
Specification Committee reacts to milestone builds: we
could add a formal approval process, or make it more
organic (the primary purpose of milestone builds is to
generate feedback from primary stakeholders; the
Specification Committee and implementors are among the
stakeholders who can provide feedback to incorporate
into a subsequent milestone build).
The Specification Committee, then, is
responsible for ratifying and promoting the output of
the open source project's final release as an official
specification. By the time we get to the point that a
Specification Project makes an official release, the
committee (and vendors) should have consumed milestone
builds and provided feedback, so that final ratification
step should be relatively straightforward.
So, I think that the spec creation
and ratification process looks a little like this:
The project proposal includes a
scope, so getting the Specification Committee's approval
seems pretty natural.
Likewise, setting the plan at the
beginning of a release cycle seems like something that
the Specification Committee should get some say in. I
tend to prefer a feedback loop model for milestone
builds rather than formal approval (but am ready to be
convinced otherwise).
Strictly speaking, the PMC approves
releases, but we may decide to give the Specification
Committee some say here. The main role of the PMC in the
release process is to ensure that the process has been
followed correctly and that the project is operating
according to the open source rules of engagement.
Ultimately, the Specification
Committee has to ratify (and promote) the specification.
In terms of coordinating the delivery
of multiple specifications, our experience with the
simultaneous release may provide some good answers. More
on this later.
The final part is the actual process
of certifying implementations. For this, I mostly just
have questions.
I can provide an overview/primer of
the EDP on the next call if there is interest.
On Tue, May 8, 2018 at 10:05 AM,
Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx>
wrote:
On 2018-05-08 8:15 AM,
Richard Monson-Haefel wrote:
> Would it be possible to simply create a
one page Jakarta EE 8 spec
> that says Jakarta EE 8 products have to
conform to the Java EE 8
> Specification and than use the existing
TCK to test and certify? I’m
> not clear on the legal aspects of that
but if that is possible we
> could actually knock out Jakarata EE 8
quickly and move on to all the
> other decisions needed before embarking
on Jakarta EE 9.
No, this would is not possible for exactly the
legal issues you mention.
It has to do with how we pick up rights to the
patents which have been
licensed via the JCP. There is no way to carry
those licenses forward,
so what we are going to have to do is stand up
"expert groups" (if
that's what we call them) that include as many
of the companies and
individuals who worked on the original JSRs.
At a minimum we'll be
looking for the "big three" patent holders
(Oracle, IBM, Red Hat) to
join into those groups so that all essential
claims to which they have
patents will be picked up by the new process.
Otherwise we will be
releasing Jakarta EE 8 with no granted patent
rights, and that would be
a big mistake.
My guess is that the above paragraph could
spur about 20 emails
questioning every aspect of it. Please resist
the temptation :) We are
working hard with the lawyers to figure all of
this stuff out but there
is still a lot a moving parts. But getting the
flows for patent rights
done correctly is very important, and is
getting quite a bit of attention.
--
Mike Milinkovich
mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx
(m) +1.613.220.3223
_______________________________________________
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://dev.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://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
--
Wayne Beaton
Director of Open Source Projects
_______________________________________________
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://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|
