I look forward to hearing if OASIS has arrived at a superior
solution.
Best regards,
Dan
Dan Bandera
(512) 286-5228
Program Director, FaaS, IoT, and Java
IBM Open Technologies, Austin, Texas
The OSGi Alliance ( osgi.org ) President and Board of Directors
From:
"Steve
Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To:
Jakarta
specification committee
<jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:
2018-06-06
04:56 AM
Subject:
Re:
[jakarta.ee-spec.committee] Interaction Between Code-First and
Specifications
Sent
by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
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,
I have decided it is time for a new
thread,
as I am starting to get lost in "Recent Edits".
Recently Bill Shannon, Ivar
Grimstad,
Steve Millidge and Scott Stark had some comments on the
interaction between
the code first approach and the specification process
requirements. 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.
Bill Shannon:
- ... 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?
- Proposed
Resolution:
- The
definition of
a Specification Project should be refined to recognize
that the Specification
Document and the TCK will be done in separate Eclipse
project managed under
the same PMC.
- Now
that there is
no single Reference Implementation, we need to fix that
in the definition
as well.
Steve
Millidge:
- 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.
- Proposed
Resolution:If you have any specific suggestions on how
to improve the wording, please
suggest or comment on the document. Personally, I don't
think that the
spec process is pushing back on code first at all. At some
point you still
have to take IP from the code and turn it into a
Specification, and that's
what we're working on. But I fully admit that I'm perhaps
too close to
the wording, and will happily take suggestions to make that
clearer.
Scott
Stark:
- ...this
looks to
be in conflict with the requirement that one be able to
create a clean
room implementation from the spec document due to the
references to the
JavaDoc produced from the external API code.
- Proposed
Resolution:
I am not seeing this. Ivar makes it clear that you end
up with a formal
specification document and that other implementations would
be expected
to move to reflect those updates.
HTH
--
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
_______________________________________________
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
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
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
_______________________________________________
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
