Maybe that's the reason to define a Platform, as the place that the
overall architecture is created and managed.
If a Working Group had 3 Profiles and no Platform I suppose it would
be up to the Working Group to decide how the 3 Profile Specification
Projects should manage the architecture of all the projects under
that Working Group, e.g., by ensuring great overlap in the
membership of those 3 Profile Specification Projects.
Wayne Beaton wrote on 10/10/18 10:39
AM:
More generally, this means that in the general
sense, nobody has overall responsibility for the architecture of
the full suite of specifications under a specific Working
Group's umbrella; rather it is the Profile projects, which have
the responsibility to present a coherent overall architecture
are responsible for influencing the projects that they leverage.
Wayne
On
2018-10-04 9:48 AM, Kevin Sutter wrote:
I agree, Bill, that we haven't
defined who owns the overall architecture of Jakarta
EE. I think we determined yesterday that the Spec
Committee does not own this architecture. From past
conversations, I think we have also agreed that it's
not the EE4J PMC. So, is it the Platform project?
This might be the logical choice, but we haven't
defined that role yet. We need to put this
definition and anointing on our list of things to
do...
I distinctly remember a conversation some months back
where this was suggested. E.g. that the architecture
role should be played by the Jakarta EE Platform
Specification Team.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java 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>,
Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
Date:
10/03/2018
06:23 PM
Subject:
Re:
[jakarta.ee-spec.committee] Specification Committee
call agenda, October 3/2018
Sent
by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
Wayne Beaton wrote on 10/ 3/18 07:51
AM:
Roles of the PMC and Specification
Committee:
PMC manages the governance process, and provides
oversight. They ensure that the open source rules of
engage are observed and the EDP as a whole is
followed. They participate in the Intellectual
Property process to ensure that requests for review
are technically sound (e.g. ensure that the use of
third party content makes technical sense). They
provide best practices. The PMC owns the software
"stack" (i.e. their view spans the concerns of all
subprojects). The PMC tends to work more at the
development/technical level.
Specification Committee owns the
overall vision of how all the different
specifications fit together. <strike>They
provide a channel for intellectual property flows (I
may not be expressing this
correctly).</strike> The Specification
Committee provides oversight for the implementation
of the EFSP and certification process on behalf of
the Working Group, owns the process of promoting and
maintaining Final Specifications
Approvals from both parties are
required for lifecycle Reviews.
The PMC is in the Project Leadership
Chain; the Specification Committee is not.
As discussed in today's meeting, the
problem with the above is that it seems like both
the PMC and the Spec Committee are providing
"architecture" and/or "vision" for the projects.
Somebody has to define the architecture and somebody
has to check that the result fits with the
architecture. I expected that the Spec Committee,
like the JCP EC, was doing the latter. I'm not sure
whether it's the PMC or the "platform project" that
does the former.
There's a theoretical problem here if one group
defines the architecture and another group gets to
say "I don't approve what you've done because I
disagree with the architecture". I think we solve
that in practice by having many of the same
individuals/companies involved in both the creation
and the approval.
I'd love it if the FAQ included examples of the
kinds of activities or decisions that the PMC and
the Spec Committee engage in, something more
concrete than "oversight" and "ensure the EDP is
followed".
The term "profile" is a flag for
marking specifications that extend branding
privileges to Compatible Implementations. Further,
we apply special voting requirements to profiles, so
we need a definition. Do we need the term "platform"
to be formally specified as part of the process?
What is special about platforms (with respect to the
process)?
I'm fine with keeping it in the process
document but not saying much about it.
Is the use of this terminology
sufficient?
"Compatible Implementation: is any
implementation that fulfills all requirements
of a Specification Version as demonstrated by fulfilling
all requirements of the TCK."
Are these statements sufficient?
Yes.
A Compatible Implementation must fully
implement all non-optional elements of a
Specification Version, must not not extend the API
(no supersetting), and must fulfill all requirements
of the corresponding TCK.
Is it sufficient to require that just
one Compatible Implement fully implement a
specification, including all optional elements?
Yes.
(Fix "not not" above.)
A Specification Version must identify
at least oneCompatible Implementation under
an Open Source License that implements all optional
elements of the Specification and fulfills the
requirements of all elements (including optional
elements) of the TCK.
By way of clarification, when we say
that a CI must implement all optional elements, does
this apply to the prerequisites? e.g. (hypothetical)
if one has to implement all optional elements of the
JSP specification; does one have to also implement
all optional elements of the servlet specification,
or only those optional elements of the servlet
specification that the JSP specification requires be
implemented?
The answer to this question, should be
an FAQ entry.
Depends on the requirements of the JSP
specification. If the JSP specification doesn't
depend on some optional elements of the Servlet
specification, the full JSP CI wouldn't need to
implement those optional elements of the Servlet
specification. In general, a JSP CI wouldn't be
implementing the Servlet spec at all, but would
require a Servlet CI to run on.
Do we need to make it clear that adding
a Compatible Implementation to a Final Specification
does not change the Final Specification? i.e. no
ceremony is required. IMHO, the process by which
Compatible Implementations get added is an
implementation detail.
What does it mean to "add" a Compatible
Implementation to a Final Specification?
As I've said previously, the specification document
should not refer to any implementations. The
Project Review should include information about
Compatible Implementations. Once the review is
complete, there's no need to update that
information, but we might want to separately
maintain a list of Compatible Implementations for a
given spec.
_______________________________________________
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
![Avast
logo]()
|
This email has been checked for viruses by
Avast antivirus software.
www.avast.com
|
_______________________________________________
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 | Eclipse Foundation, Inc.
Meet us at EclipseCon Europe 2018: LUDWIGSBURG, OCTOBER 23 - 25
_______________________________________________
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
|
