Re: [jakarta.ee-community] JAX-RS 2.1.1 Available On Maven Central

[arjan tijms <arjan.tijms@xxxxxxxxx>]

Hi,

I completely agree too. We can add whatever feature to the spec, and then before it goes final we can quickly implement it in some implementation (effectively playing the role as *a* RI). When it’s implemented, the spec can go final.

So we’re all saying the same thing: we can add features to JAX-RS, but a product has to implement that feature :)

Practically I’d propose the following though: we create an API issue for a new spec feature, if that issue has support, we implement it in some product (likely the product the one who pushed most for the feature is most associated with, eg for me that would be Jersey). 

If it’s implemented in said product the API PR (if any) can be accepted. Pending the release of the spec process, I’d imagine the API would at some point after that be proposed for the actual spec and, if applicable, text spec would be written for it. (But the Jakarta EE spec process hasn’t been released yet, so we’ll have to wait for that to make definite plans)

Kind regards,

Arjan

On Wednesday, September 12, 2018, Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:

I agree completely. With "product" I not only mean closed-source off-the-shelf stuff, but also open source read-to-use applications and frameworks, like "Jersey", "CXF", "Eclipse IDE". So to sum, up, we meant the same: One out of "Jersey", "CXF", "RESTeasy" MUST have proven the benefit of a new feature BEFORE we discuss the adoption of that feature into the JAX-RS API specification. Not vice versa. :-)

-Markus

 

From: jakarta.ee-community-bounces@eclipse.org [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of Mike Milinkovich
Sent: Mittwoch, 12. September 2018 15:48
To: jakarta.ee-community@eclipse.org
Subject: Re: [jakarta.ee-community] JAX-RS 2.1.1 Available On Maven Central

 

It may be simply that I am reading too much into your use of the word 'product'. When I hear 'product', I think proprietary-licensed intellectual property. Maybe you think of the word differently. My definition of code first includes community-led open source projects which are seeing adoption, even if they have not been productized by a vendor.

The spec process requirements did state that at least one open source implementation of a specification version must exist before the spec can be adopted. So I think we're in agreement on that point.

On 2018-09-11 4:43 PM, Markus KARG wrote:

Mike,

 

yes I am pretty sure it is a misunderstanding so I kindly ask for some more clarification.

 

What kind of code do you have in mind when saying "code first" other than an existing a product, when at the same time you write "Personally I think that specifying something before (a) it has been implemented and (b) the market has demonstrated an interest in it, is unlikely to succeed."? Only a product which is already implemented and publicly available is able to fulfil (a) and (b). Can you please make an example of what kind of artifacts type we talk about here?

 

This does not imply the smallest common denominator of ALL existing products. It just means that SOME (at least one) product already must have such a feature before it is added to the spec.

 

-Markus

 

From: jakarta.ee-community-bounces@eclipse.org [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of Mike Milinkovich
Sent: Dienstag, 11. September 2018 21:53
To: jakarta.ee-community@eclipse.org
Subject: Re: [jakarta.ee-community] JAX-RS 2.1.1 Available On Maven Central

 

This is just a misunderstanding.

I have said many times that we want Jakarta EE to have more of a "code first" approach to innovation, rather than the old JCP approach of "spec first". (Interestingly, the JCP is simultaneously evolving to a similar model so that it can better serve the needs of OpenJDK.)

I never meant to imply that future specs would simply be the lower common denominator of vendor's products. What I meant was that as an open source community we should try out experiments in code, and then specify when we have some reason to believe that the code is useful. I think we can all think of EE specifications in the distant past that could have benefited from such an approach.

Most of this "code first" thinking was about new specs. How existing specs are evolved up to the spec projects themselves. Personally I think that specifying something before (a) it has been implemented and (b) the market has demonstrated an interest in it, is unlikely to succeed. But this class of concerns can be addressed by tight iterative development of the spec, TCKs and one or more open source implementations.

None of this is meant to imply a free-for-all. Writing a spec that the vendors won't implement is useless. But so is writing a new version of an existing spec with zero useful innovations. That dynamic drives the difficult negotiations necessary in any spec process --- arriving at the correct balance between great ideas and what can realistically be implemented.

HTH

On 2018-09-11 1:53 PM, Markus KARG wrote:

Mike,

 

in fact you told me in person at ECE 2017 that you do NOT want specifications to be developed first, and then added ontop of the products, but that you want the specifications to describe the EXISTING features of the existing products. I can't help it if you didn't want to say or imply that, but it was what I (and others in the room) understood. This might be a misunderstanding, so let's restart from scratch:

 

So a specification project MAY invent new features in the specifiation FIRST, before ANY product actually implements this? Good for us! :-)

 

-Markus

 

From: jakarta.ee-community-bounces@eclipse.org [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of Mike Milinkovich
Sent: Dienstag, 11. September 2018 16:22
To: jakarta.ee-community@eclipse.org
Subject: Re: [jakarta.ee-community] JAX-RS 2.1.1 Available On Maven Central

 

On 2018-09-09 7:18 AM, Markus KARG wrote:

Unfortunately this is not the EFs official policy. According to EF president Mike Milinkovic, all EE4J API projects shall NOT force features from vendors, but instead shall only wrap existing features under a common hood. What I did is adding feature to API AND to Jersey parallel, and encouraged other vendors to follow.

Markus,

I don't recall ever making the statement above. It's possible that there's been a misunderstanding.

I do expect innovation to happen in the specifications once we get the process going. There will have to be some give-and-take between the aspirations of the community and the vendors who have to bear the cost of implementing them. But I see that as a normal part of any specification process that desires to deliver new innovations.