[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-spec.committee] Interaction Between Code-First and Specifications
|
+1
On Wed, Jun 6, 2018 at 5:56 AM, Steve Millidge (Payara)
<steve.millidge@xxxxxxxxxxx> wrote:
> 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
>
