| Re: [jakarta.ee-spec.committee] Interaction Between Code-First and Specifications |
IANAL (especially not a USA software patent lawyer).
However my perhaps simplistic solution is to modify the standard Eclipse Contributor Agreement and membership agreements to ensure the required IP flow at contribution time. That would at least enable a code first approach within the EF with later standardisation.
Steve
From:jakarta.ee-spec.committee-bounces@xxxxxxxxxxx <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
On Behalf Of Bill Shannon
Sent: 01 June 2018 19:59
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>;
Ian Robinson <ian_robinson@xxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] Interaction Between Code-First
and Specifications
I
agree.
Many of you have been thinking about this problem since the JCP was first
created. Do you have a proposal you can share?
Ian Robinson wrote on 06/ 1/18 04:18 AM:
+
1 to this and Mark's comments on another branch of this discussion:
Mark Little wrote on 01/06/2018 07:47:28:
> IP flow is very important. However, if we come up with a process that
> is driven solely by that aim and the end result is something that
> prevents code-first development and rapid iteration then I think we
> need to go back to the drawing board. Or put another way, let's make
> it clear that IP flow is only as important as code-first development.
>
> Mark.
Regards,
Ian
Ian Robinson,
IBM Distinguished Engineer
WebSphere Foundation Chief Architect
IBM Hursley, UK
irobins@xxxxxxxxxx
Admin Assistant: Janet Brooks - jsbrooks12@xxxxxxxxxx
From: "Kevin
Sutter" <sutter@xxxxxxxxxx>
To: Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date: 31/05/2018
23:59
Subject: Re:
[jakarta.ee-spec.committee] Interaction Between Code-First
and Specifications
Sent by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
At the risk of having to own this picture... :-) I have attempted
to capture Ivar's description in a Google Drawing. It's kind of cryptic,
but if it helps with our discussion tomorrow, great. If not, it didn't
take up too many cycles... I also took a few liberties to fill in
a couple of holes in the description, but I know there are many more to
fill...
https://docs.google.com/drawings/d/1TvP378n0SH35CLOVxsuump8vJ3ErMt0QamXGgO67TwE/edit?usp=sharing
(I currently have this on my own Google drive. If this is useful,
it could be moved to the Jakarta EE drive for a wider editing audience.
Right now, I just have provided the link allowing comments.)
---------------------------------------------------
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: "Kevin
Sutter" <sutter@xxxxxxxxxx>
To: Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date: 05/30/2018
05:14 PM
Subject: Re:
[jakarta.ee-spec.committee] Interaction Between Code-First
and Specifications
Sent by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
> For
the record, I think Ivar's email is so spot-on we might want to add it
to the document as a use case to help elaborate on the requirements.
+1, with a couple of clarifications per my earlier email...
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 groups (individuals) 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 possibly
doesn't resemble the original feature.
Thanks.
---------------------------------------------------
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: Mike
Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>
To: Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date: 05/30/2018
04:59 PM
Subject: [jakarta.ee-spec.committee]
Interaction Between Code-First and Specifications
Sent by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
All,
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
_______________________________________________
jakarta.ee-spec.committee mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit