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
|
