Don't get me wrong, I'm on your side. I just want to make sure that we correctly understood Mike's policy, and that nobody gets the impression that he can just invent fancy features that nobody ever will implement. A spec project is definitively not the place where users may clutter the issue tracker with their solitair wishes. So I follow your idea in case a feature is well thought and hopefully comes from a product vendor or at least experienced key user. Otherwise the committers of the spec project will soon have lots of work to discuss and close lots of unfeasible issues. Also I want to express the independence of projects. The spec committee's job is to define rules for specification. Not processes where to put feature wishes. Just because we currently seem to mix up both in our discussion. -Markus From: jakarta.ee-community-bounces@xxxxxxxxxxx [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of arjan tijms
Sent: Donnerstag, 13. September 2018 00:12
To: Jakarta EE community discussions
Subject: Re: [jakarta.ee-community] JAX-RS 2.1.1 Available On Maven Central Hi, Quickly implementing is fine. It's all relative though, as "quickly" can mean either a couple of weeks or a day (this depends on the complexity really). I previously used the phrase Just In Time, which describes the concept perhaps better. I once again agree that it needs some time to gather feedback from users (community), but that was exactly what I was saying before ;) The feedback process can be facilitated by using the time tested milestone approach. For instance, for EE Security, we introduced the concept of an identity store using an API issue. This was then implemented in Soteria, and various milestones of Soteria were published to gather (community) feedback. Based on that feedback, the identity store feature was tweaked later on. So that's I think a good example of real-world user feedback, and code (product) first ;) We basically followed the exact same process in JSF and Mojarra as well. All API issues were immediately implemented in Mojarra, and Mojarra published regular milestones which users used to play with (there even was at least one user who used those in production, something we didn't recommend, but the user did so anyway ;)). As mentioned, the Jakarta EE spec process is still being worked on (I participate in this process as mentioned earlier), and once it's final we can really say something about it here, but in comparison, the JCP had several mandatory review moments during the spec cycle as well. So eventually it's a combination between committer agreement, community feedback based on milestones, and likely one or more official review moments. While I really like to agree, this is not 100% what Mike said. Mike told us that the feature has to be proven its use in a product. Quickly hacking it into a product just for the sake of getting it covered by code is the inverse of that. So at least you have to wait for some weeks to collect feedback from the users of that product to see if they love or hate the feature. In core, I agree to the process, but it implies to automatically -1 all API PRs that have not proven this real-world user feedback. We can even shorten the process: The vendor willing to implement the RI for this feature can simply provide a PR once his feature was loved by his users. No need for an API issue before. And that is simply what I told right from the start: Product first, not spec first. -Markus 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)
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
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
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 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.
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
|
