[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-spec.committee] Recent Edits
|
I like the code-first approach, but I have
a few comments...According to Ivar's description, this
neat new feature was first developed by CXF. Then, the JAX-RS API
project picked up the idea and solidified the API in the next release of
JAX-RS 3.0? And, then the API is proposed to the Spec committee?
That seems to be going just a bit too fast. What happens if
the Spec committee declines the proposal (for whatever reason)? Now,
we have JAX-RS 3.0 with an API that is not a standard. And, all of
the previous incarnations of the JAX-RS API were standards (due to Java
EE process). JAX-RS is now no longer a standard.Instead, I think the JAX-RS API team
needs to propose updates to the APIs to the Spec committee *before* releasing
new versions of their API. If we want to experiment with the JAX-RS
APIs, then that's where projects like MicroProfile come into play. We
could use the MicroProfile RestClient component as an example. The
RestClient is a type-safe alternative to the JAX-RS client interfaces.
MicroProfile has produced a version or two of this API. The
JAX-RS team is currently evaluating this RestClient as a possible feature
for the next rev of JAX-RS API. But, again, we should push these
type of API updates through the "much more efficient spec process"
at Jakarta EE to ensure that the JAX-RS API stays consistent.The other thing we need to ensure is
that we at least offer to keep the principals involved through out this
process. Whatever CXF or MicroProfile created, it's bound to change
slightly as it goes through the spec process. These people should
continue to be involved to ensure that the intent of the original feature
is not lost. Being an open community, this should not be an issue.
But, it's something that we should emphasize. We don't want
it to seem like the APIs are thrown over the wall to the Spec process and
out comes something that doesn't resemble the original feature.
---------------------------------------------------
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/kevinwsutterFrom:
"Steve Millidge
(Payara)" <steve.millidge@xxxxxxxxxxx>To:
Ivar Grimstad <ivar.grimstad@xxxxxxxxx>,
Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>Date:
05/30/2018 03:59 AMSubject:
Re: [jakarta.ee-spec.committee]
Recent EditsSent by:
jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
Hi Ivar, My thinking aligns with the code first
approach you outline. Which I think is the root of my confusion the specification
process discussions seem to be pushing back towards the spec first approach
with Expert Groups etc. Steve From: Ivar Grimstad <ivar.grimstad@xxxxxxxxx>
Sent: 30 May 2018 09:49
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Cc: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] Recent Edits Hi, I think we are confused since we are so
used to thinking "spec first", while we now should be thinking
"code first". In the spec-first approach, it makes perfect
sense to group the API with the spec. But when we turn around to code-first,
I think they should/must be separated. Consider the following scenario for
a code-first approach:Let's say Apache CXF has some cool features
that partly overlap with some features of RESTEasy. Jersey may or may not
have these features. The JAX-RS API Project1. Decides to extract the best parts from
the implementations and produce a standard API for them.2. Release JAX-RS 3.03. Propose to the Jakarta EE Specification
Committee to standardize through Jakarta EE a. A EE4J project (such as
JAX-RS API project) would go through the EE4J PMC b. A standalone Eclipse Foundation
API project would go through their PMC c. A project outside the
Eclipse Foundation (e.g. Bean Validation) would go through their equivalent
to the PMC The Jakarta EE Specification Committee1. Approves the suggestion (or suggest
changes or decline...)2. If approved, mandate the Jakarta EE
Spec project for JAX-RS to produce the specification The Jakarta EE JAX-RS Specification
Project1. Produce the specification document which
includes: a. A human readable description
of the API with references to the API JavaDoc b. Define what MUST, SHOULD,
COULD, SHOULD NOT etc. be implemented in order to comply with the specification c. Assertions backing up the
MUSTs, SHOULDs, COULDs and SHOULD NOTs on an agreed up format to form the
basis by the TCK The JAX-RS TCK Project1. Use the assertions from the spec to
create/update the JAX-RS TCK2. Seek approval that the TCK does what
it is supposed to from the Jakarta EE Specification Committee The Implementation projects (may or
may not be Eclipse projects)1. Adjust their implementations to implement
the API2. Test their implementation against the
TCK Whether, or not, JAX-RS 3.0 should be a
part of Jakarta EE X is up to the platform project/Specification Committee
to decide. Does it make sense, or am I way off? Ivar On Wed, May 30, 2018 at 12:08 AM Bill Shannon
<bill.shannon@xxxxxxxxxx>
wrote:I'm starting to become concerned/confused
about this as well.
I think we were previously expecting that a specification project would
manage the specification document, the source code for the API classes,
and the source code for the TCK. Assuming we need special rules for
specification projects, do we really want those special rules to apply
to the API and TCK, which after all are just source code projects?
The API classes are hard because they mix specification with (varying amounts
of) implementation. But none of the IP issues for the spec apply
to the TCK, right? Maybe the TCKs should be in separate code projects
that follow the normal EDP rules?
Steve Millidge (Payara) wrote on 05/29/18
02:28 AM:I share Ivar’s concerns here. I am also confused by the definitions and
the developing special nature of this specification project and how that
is going to work in practice with the standard Eclipse API and TCK projects
that will live under the EE4J PMC. So forgive me if I get this wrong are we
saying; Specification Project -> creates Document,
Specification Implementation, TCK?A normal EE4J project under the PMC creates
just the API? Or are we saying Specification Project
just creates the Document and must ensure there is a TCK, API and Specification
Implementation before the Specification can be released. Also given the document just essentially
describes the API and behaviours under the API how is the Specification
project going to control/influence the work of the API project working
under usual EDP rules of engagement? I’m afraid I’m a fairly practical person
and I am now confused about practicalities of who is doing what. Thanks
Steve From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>On Behalf Of Ivar Grimstad
Sent: 25 May 2018 18:02
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] Recent Edits Hi, I think we should tread carefully here
so we don't become a corporate club where you have to pay to play, which
is exactly what critical voices in the community have warned against. I can understand the reasoning behind the
wish for a company to being able to replace a committer on a project. But
at the same time, if a corporation is allowed to do that it should probably
apply to individual committers as well. E.g. someone that wants to resign
from the project for some reason and give the reigns over to someone else.
By doing so, we are going against the Open Source Rules of Engagement defined
by the EDP (https://www.eclipse.org/projects/dev_process/development_process.php#2_1_Open_Source_Rules_of_Engagement).
So be prepared for a storm! This will not be well received by our critics... Ivar On Fri, May 25, 2018 at 2:56 PM Richard
Monson-Haefel <rmonson@xxxxxxxxxxxxx>
wrote:Below .... On Fri, May 25, 2018 at 4:02 AM, Mike Milinkovich
<mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>
wrote:Richard,
We (the EMO) are thinking about this, and how we could make it work if
we decide it is the right thing to do.
Two points:- I find it surprising that the small-company
guy is arguing for the corporate approach. I realize that this is quite
typical in standards organizations. Is everyone else on the list comfortable
that this explicit corporate presence is desirable?
Well,
like any other organization that is dedicating resources to the effort
of Jakarta EE, we (Tomitribe) want to ensure that we benefit from that
investment. When an engineer works on a Jakarta EE specification, it costs
the company money in terms of salary, but that's not all. Often the employee
will rely on other resources in the company such as people or equipment.
None of this is free. I am a committer for the EJB Specification
project. Tomitribe is counting on me to make valuable contributions
that will result in a stronger specification which means a healthier market
for Tomitribe and everyone else. If I were to leave Tomitribe, they
would want to protect that investment in time and energy by replacing me
with another qualified individual. My time contributing to specifications
is not a sunk cost. When a company's representative is added
to a Specification Project its done on merit, just like adding an individual.
It's expected that the company can contribute, regardless of the
representative, real value to the definition of the specification. The
company has to have demonstrated expertise in the area concerned.- I hope that you are prepared to
argue for this when our friends like Markus Karg take us to task for being
a bunch of corporate shills ;)
Of
course. -
On 2018-05-24 10:58 AM, Richard Monson-Haefel wrote:Thanks, Mike. At this time committers are defined as
"individuals." I would like to see that expanded to include "representatives".
A representative is the role of committer in a project that can be
occupied by an employee of the company that is represented. Not sure
if that makes sense or not. You can be nominated and elected as a
committer to a project as either an individual or as a representative of
a company. If an elected representative leaves the company they were
elected to represent, the company has the option of appointing a new representative.
If the project wishes to also keep the original representative they
can be re-nominated and elected as an individual or as a representative
of a different company. A representative committeris equal in all other ways to an individual committer. On Thu, May 24, 2018 at 4:09 AM, Mike Milinkovich
<mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>
wrote:
Please do not worry about how Wayne and I get the approvals in place for
any necessary process changes. I'm confident we can make what we agree
to happen. Let's figure out what the right solution is, and then the EMO
can figure out how to implement it.
On 2018-05-24 1:36 AM, Richard Monson-Haefel wrote:I believe changes to the Eclipse Development
Process require approval by the Eclipse Board, so if a rule change is necessary
it would need to be proposed to the board. Whether or not an exception
can be made for just the EE4J Working Group or if the change would need
to apply to all Working Groups, I do not know. If the rules germane to
this issue cannot be changed, than instead of a rules change it could be
considered a “courtesy” that is commonly extended to companies whose
whose employee, elected as a committer, has ended their employment with
that company. For example: Project X has 10 committers with names (A, B,
C ... J). Committer B worked for ACME Company when elected to a Specification
Project. When Committer B is nominated they declare that although they
are individual they also are an official representative of ACME Company.
This proclamation is not binding in anyway, but is simply informative
part of the nomination. Committer B announces that they are leaving the
ACME Company to become independent but will sign a new Committers Agreement
as an Independent (or their new company will sign one) and will stay on
Project X. The ACME Company makes a request that another employee,
Ms. K, me nominated as a committer to Project X. The Project Lead, as a
courtesy to the ACME Company, can choose to nominate Ms. K. The vote is
taken according to normal Eclipse Development Handbook and Ms. K is either
elected a committer or not. On Wed, May 23, 2018 at 7:22 PM Bill Shannon
<bill.shannon@xxxxxxxxxx>
wrote:That's a start, but that makes it clear
we're inventing new rules for Spec Projects that are different than any
other Eclipse project. Is there a better way to "overlay"
the Spec Project rules on top of the existing Project rules?Richard Monson-Haefel wrote on 05/23/18
02:34 PM:Good point. Here is a counter proposal: In addition to accepting individuals to
a Specification Group, the group lead or the group can nominate/elect (or
whatever) a representative of an organization. If the represenative
leaves that organization, the organization can nominate a replacement represenative.
The original representative can remain on the Specification Group
as an individual or perhaps representing some other company, but the company
that originally invested in that represenative has the right to nominate
a new represenative. The newly nominated represenative can be subject
to a vote by the group. That way the organization that lost the represenative
has the oppourtunity to maintain its place at the table but is not an automatic
“pay to play” contributor. I think that protects the investment made
by the organization when it has payed the representative salary and gave
that time to the Specification Group without making it a “pay to play”
situation. So there can be individual group members and organizational
group members. On Wed, May 23, 2018 at 4:00 PM Bill Shannon
<bill.shannon@xxxxxxxxxx>
wrote:Richard Monson-Haefel wrote on 05/23/18
07:28 AM: Depending on the membership level, an organization
should automatically get a seat on any specification project they want
but should excercise self-restraint to focus on those specifications germane
to their products. Why, for example, should a company become a strategic
member if it cannot have a seat at the table? So, if you pay then you can play?
What about the people who don't pay?
At the JCP, the Spec Lead would decide whether an expert was qualified
to be on the expert group. We ran into quite a few people who clearly
only wanted to be on an expert group so that they could add that to their
resume. We rejected many of those people.
If "expert group members" are Committers on a Spec Project, who
qualifies the Committers? After the Project is created, I assume
it would be the Project Lead. Before the Project is created, is it
just the person who proposes the project? And you're suggesting that
the Project Lead would have no choice but to accept any Committer proposed
by a paying Member?
_______________________________________________
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 listjakarta.ee-spec.committee@xxxxxxxxxxxTo change your delivery options, retrieve
your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
--
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
--
Java Champion, JCP EC/EG Member, EE4J PMC, JUG Leader
_______________________________________________
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
--
Java Champion, JCP EC/EG Member, EE4J PMC, JUG Leader_______________________________________________
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
