Kevin Sutter wrote on 05/30/18 03:14 PM:
> 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.
I agree. If the JAX-RS API project is experimenting with a new API,
it should release "3.0.pr1" or some non-final artifact.
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.
Where and how to "experiment" is a good question. I believe the
EE4J and Jakarta EE processes MUST allow and even encourage such
experimentation. If we drive projects to experiment elsewhere,
we've failed.
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
Completely agree.
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
|
