I doubt that it is the EF which causes the delay, and I doubt the other party will speed up just because the PMC members want them to. But certainly it is worth a try. They all read this. Let's see what happens. Until then I would keep the preliminary schedule as-is, since it is *preliminary* already. Once Oracle made up her mind when they are willing to let us publish new features, we can overhaul the plan and make it final. -Markus From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of reza_rahman Sent: Freitag, 3. August 2018 20:11 To: jaxrs developer discussions Onc Subject: Re: [jaxrs-dev] [Discuss] Initial Roadmap / Preliminary Release Schedule What would be best is to put together some well thought out documentation on what the factual basis of the concerns and expectations are. Since JAX-RS and Java EE Security seem to be the only specifications with any sign of life, maybe the concerns get started in this context. There was some sign of life in JMS but that seems to have died off completely for a while. The key is I think getting the major Jakarata EE stakeholders including the Eclipse Foundation behind these concerns and getting some sort of real resource/timeline commitments. If the transfer process keeps dragging on, it will just compound the problem that was created in the Java EE 7 and Java EE 8 timeframes. I think we should try this within the Eclipse Foundation framework first and involve the broader community such as the Java EE Guardians as a last resort if all efforts to get some kind of commitments fails. Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone -------- Original message -------- Date: 8/3/18 1:53 PM (GMT-05:00) Subject: Re: [jaxrs-dev] [Discuss] Initial Roadmap / Preliminary Release Schedule I've to say I'm starting to get slightly worried. The lack of any progress, or even more the lack about details regarding this progress is worrisome. Like Markus, I'd also love to see a minor version of EE Security/Soteria released before long, but that seems difficult if not impossible at the moment. I appreciate all the hard work both Oracle and Eclipse have been doing, and I fully understand it takes time to vet and clean all the code that still has to be transferred (like HK2 and GlassFish itself). But specifically the fact that there's no clarity still about usage of the javax.* packages is troublesome. I agree the pace seems very slow and no one seems to know what the exact timelines are. Maybe this is a concern that should be escalated to Jakarta EE stakeholders? Keeping pushing MicroProfile only goes so far while competitors just keep rolling forward. Java EE was already behind, how much catch up will Jakarta EE need to do?
On 8/3/2018 1:23 PM, arjan tijms wrote: Hi, Seeing how things are currently progressing I think targeting spec releases or even API releases of JAX-RS (those are technically not quite the same anymore) for 2018 is quite challenging. We'd still need the TCK transferred, clarity about the spec documents and the agreement over the javax.* packages. Even the Jakarta EE spec process itself is still being worked on. At the rate things are currently going I'd be surprised really if fall 2019 for the first new spec/api release (JAX-RS 2.2) is possible. I'd like to propose setting JAX-RS 2.2 tentatively for end of 2019. We can always move it back if the transfer process unexpectedly speeds up, but at the moment I think that's a more realistic roadmap. I.e. better underpromise and overdeliver than the other way around. I think Java 8 is very important still for JAX-RS 2.x, but not important at all for 3.x anymore. -Markus Regarding Java 11 I actually meant "Compiles using Java 11", i. e. people cannot load that JARs anymore on a Java 8 VM. So it might be a big deal if people must stay compatible with Java 8 VMs. I think Java 8 compatibility is the crux of this discussion. Is that still important? I think JAX-RS 3.0 would be the right time to drop Java 8 compatibility in preparation for future work. In fact I constructed the roadmap around what the committers are able to deliver, not just what users would be interested in. In the end, someone has to do it, and we're no only talking about API, we talk about pushing out releases for all existing products, as the EF does not allow us to do an API without at least one fully compliant product per release. JPMS support and Java 11 support are somewhat separate issues. Generally I don't think there are any API changes to consume for JAX-RS from Java 10 or Java 11. It is really just a matter of compatibility testing, which is not that big a deal. Personally I think JPMS support for JAX-RS alone is a relatively minor feature. I imagine most implementations won't have much trouble doing this and perhaps JAX-RS alone supporting JPMS is not that interesting to users either. Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone -------- Original message -------- Date: 7/28/18 5:59 AM (GMT-05:00) Subject: Re: [jaxrs-dev] [Discuss] Initial Roadmap / Preliminary Release Schedule thanks for sharing your ideas! I have tried to add most of it into an updated preliminary schedule: Please be so kind and check this new plan. It now contains more releases in the same time frame so I could add more of your requested features. Now before we can vote on it, we need another round of feedback. In particular, the following questions arise: - From a purely formal standpoint, can we do JPMS and Java 9 in a minor version increase or does that enforce a major version increase? - Do we really only want Java 9 in 2019, or shall we directly jump on Java 11 in half a year from now? Thanks for your feedback! From: Markus KARG [mailto:markus@xxxxxxxxxxxxxxx] Sent: Samstag, 21. Juli 2018 14:35 To: 'jaxrs developer discussions' Subject: RE: [jaxrs-dev] [Discuss] Initial Roadmap / Preliminary Release Schedule yes, if we remove something in 3.0 then we MUST deprecate it in 2.2 or 2.1.1. But this has to be voted. IIRC we have not yet voted about any particular content of neither 3.0 nor 2.2 nor 2.1.1, so I just picked what I understood to be common sense of the various discussions so far. Feel free to open an issue wrt deprecating @Context and set the linked milestone to 3, which effectively opens the possibility for reviewing and voting. Thanks for getting it written. Does 3.0 imply *removing* @Context and other related stuff. If so, those features should be deprecated in a previous version to give users a chance to migrate. _______________________________________________ jaxrs-dev mailing list jaxrs-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jaxrs-dev _______________________________________________ jaxrs-dev mailing list jaxrs-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
_______________________________________________ jaxrs-dev mailing list jaxrs-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
_______________________________________________ jaxrs-dev mailing list jaxrs-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
|