Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] Jakarta EE 8 Specs in PDF

Werner Keil | JCP Award Winner, JSR 385 Spec Lead, JSR 354 Maintenance Lead | Jakarta EE Specification Committee Member | Apache Committer | DWX 2019 AdBoard Member, Track Chair

Twitter @wernerkeil | @UnitAPI | @JSR354 | @TamayaConf | @OpenDDR | #EclipseUOMo

Skype werner.keil




On Tue, Sep 17, 2019 at 5:25 PM Santiago Pericas-Geertsen <santiago.pericasgeertsen@xxxxxxxxxx> wrote:

I don't have the exact URL here but if you check the thread you'll find it. 
There are at least 3 historical committers including the likes of Arjan who may simply have a lot on his plate, not sure if he stopped for another reason. 

 Arjan does regularly comment on issues related to Jakarta REST. You can check the archives.



It is here just in case: https://projects.eclipse.org/projects/ee4j.jaxrs/who And Arjan listed as "historical committer", not sure, what Eclipse.org uses for that, but actual code commits to the repo may be a reason or a committer decides to step down from active contribution. Github or Bugzilla tickets have no influence on that or the statistics.
 
You or your or predecessor should know the case where at least one former EG member from Red Hat at the time resigned over a dispute or something.

 That was way before Jakarta, your stated "high fluctuation even now under Eclipse/EE4J/Jakarta EE”.


I mentioned troubles including this resignation in the thread earlier, the mention of recent activities under Eclipse came a bit later after Markus wrote some stuff.
 

MVC has a couple of issues, also regarding its possible inclusion in Jakarta EE. I heard several first hand by its Spec Lead Ivar who did not exaggerate kindly calling me "The JCP guy" yesterday at CodeOne ;-)

 I don’t know how this relates to your previous statement about JAX-RS and MVC.

I mentioned that MVC had multiple issues, too. https://jcp.org/en/jsr/detail?id=371 shows there was a Renewal Ballot due to inactivity which probably came from the overall stoppage by Oracle before Java EE 8.  Being dependent on an also  more volatile and still shaping foundation like JAX-RS (as opposed to the much older Servlet Spring MVC uses) which in addition had the same stoppage issue around that time (2016ish) certainly had an effect on MVC. 
There also were design choices the new Spec Leads reversed in some cases which also did not make it easier for them and their JSR.



The duplicate spec at Microprofile for Rest Client was seemingly overlooked, but maybe as project lead you know best, if it would be good to contribute those things back to Jakarta Rest or they do something not worth standardizing. 

 It was not overlooked. The notion of a declarative client API was discussed as part of the JAX-RS 2.0 spec many years back and before MP started (I’m sure that’s archived somewhere), and not everyone was in agreement to include such an API despite it already being supported by some vendors. In this regard, there’s absolutely nothing wrong for other specs to build on top of JAX-RS, not everything needs to be part of the core.

Other "Microframeworks" like Spring Boot or Dropwizard beside several others also do, either Servlet, some use JAX-RS.  
" despite it already being supported by some vendors." sounds like it could benefit those vendors if some day there could be inspirations into the Jakarta EE spec as well, but you said they talk to each other, so that is a good first step.

Werner


— Santiago


Santiago Pericas-Geertsen <santiago.pericasgeertsen@xxxxxxxxxx> schrieb am Di., 17. Sep. 2019, 15:32:


On Sep 13, 2019, at 5:00 AM, Werner Keil <werner.keil@xxxxxxxxx> wrote:

Last but not least Microprofile spawned off a REST Client Spec that at least partly competes with Jakarta REST outside Jakarta EE which adds even more confusion and places people have to look if they write an app that uses both. 

 Writing any MP application would require looking in multiple places. MP’s foundation is CDI, JAX-RS, JSON-[BP], an these specs exist there only by reference.

 To be clear, the MP REST Client spec (like OpenAPI) builds on top of JAX-RS and provides a declarative approach to building clients (and no support at all for building actual services).

 Thus, I don’t think compete is the correct verb here. There is an overlap, yes, in that JAX-RS provides a non-declarative approach for clients as well, but the two can co-exist perfectly fine, with developers choosing their preferred flavor. 

 FYI, the idea of aligning these efforts has been discussed [1].

— Santiago

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

Back to the top