Some MP Projects like OpenAPI are merely „glue“, there is no real space for Jakarta EE to specify anything on ist own, while for gRPC much like REST or Servlet it’ll require more around that external specification than a tool. You won’t have a programatic runtime using the OpenAPI project, the annotations are mostly for documentation purposes like some in Jakarta Annotations e.g. @Generated. Well, actually there was no special reason for me to mention OpenAPI but is there a standardized way to document an API today in Jakarta EE space? MP has done it. I guess there is no reason for someone not to ask for it to be done in Jakarta EE also. One could argue that gRPC is also a tool but we see significant adoption and trends hence the spec. Tool or not, if it is useful I see no problems adding to Jakarta EE. Hi, Some see it like that, and it’s not the first time that standards evolve from popular project that are not standards but developed more or less open: - Hibernate was a major influence to JPA
- Spring Batch became more or less a blueprint for the Java Batch Standard now Jakarta Batch
- Jakarta DI (formerly JSR 330) was the most common and minimal denominator of Spring and other DI frameworks, mainly Guice
Either way, I guess the biggest competition by MP has always been the Spring stack and not really Jakarta EE given they all use Jakarta EE, so if something matures and gets widely adopted to be standard-worthy, then it’s for the good of all involved contributors. I personally was a little puzzled to see Jakarta gRPC being proposed, because gRPC is a CNCF incubation project and it should still undergo quite a few changes before maturing there, so it could have been MP-gRPC first as well. REST Client is a tiny Extension to Jakarta REST, it never felt really at home, but why do you think OpenAPI should go to Jakarta EE and what’s the Benefit there? It is a tooling project with the tagline This MicroProfile specification aims at providing a unified Java API for the OpenAPI v3 specification, that all application developers can use to expose their API documentation. So while lower level protocol specs like REST or even gRPC feel well towards ultimately becoming part of the Jakarta EE platform, how do we Benefit from a tooling project, that is not used at runtime? Werner There are more specs under the MP umbrella that could be of interest to Jakarta EE. If the Jakarta EE project re-specify them in any way (including adoption) I wonder what MP project will become aside, maybe a specification incubator until Jakarta EE project catches up. This to me seems very likely as Jakarta EE project seems to be moving at the greater speed atm and will probably overrun MP regarding innovation in the near future. Anyhow, it is important to resolve this issue now as we do not want to be debating about lets say, REST Client or OpenAPI in two weeks time. On Mon, 14 Nov 2022 at 11:46, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote: My biggest concern in these debates is the ability to support both standards in a single product as we have since the dawn of MicroProfile. Therefore whatever solution gives me the ability to do that without disruption to our customers is the solution I will vote for 😊 Architecturally it would be nicer if latest MP was built on top of latest Jakarta EE Core Profile and there were no circular references between the initiatives to unpick. Therefore I prefer that Jakarta EE does not reference MP. Although that is not insurmountable. In this particular case MP-JWT could impose additional integration requirements in its spec when run on a runtime that also supports Jakarta Security? Steve I will add one more suggestion to the list: · Don't reinvent wheels by duplicating the effort. Encourage one or the other to consumer specs from the other. I see allowing Jakarta EE directly consuming technologies from MP has minimal disruption to the end users. Having duplication in both communities does not bring value to the end users but confusion to them. In addition to that, it is a duplication effort to implement both and maintain them for the runtimes. It seems that the claim of Jakarta EE not allowing depending on MP was somehow accepted without asking why. I saw the argument of MP allowing backward incompatible changes while Jakarta EE does. That was incorrect. Look at CDI 4 for an instance. It introduced many compatible incompatible changes from CDI 3.0. Another argument of not depending on MP Config, at the moment, there is no configuration solution as yet for Jakarta EE. MP Config is the only solution. It is absolutely viable for the spec to spec the configuration support while the impl can freely choose which configuration they want. I think we had a long conversation without much agreement made. It might be better to have a call to discuss this further, so basically I am +1 on what David suggested to have a meeting to discuss the technical concerns. Anyone else? I would also like to understand whether we want MicroProfile and Jakarta EE to collaborate or compete. I hope we all want them to collaborate, it's just not clear to me what some people understand as collaboration. · Moving functionality or even whole specs between MicroProfile and Jakarta EE -> collaboration · Duplicating functionality -> competition · Forcing one or the other to consume specs from the other -> competition I think the last point above is what is causing all the controversy and disputes in this thread. I believe that collaboration should be voluntary, not enforced. And therefore it's not collaborative to prohibit Jakarta Security to implement support for JWT, if the Security team wants to do so and even planned to do so even before MP JWT existed. And we all know that Jakarta EE cannot depend on MicroProfile specs, for various reasons already discussed elsewhere. It's simply not an option even though it may seem logical. For me, collaborative means that both MP and EE try to find a solution that is suitable for both. I see one such solution, which I already mentioned: · JWT support is added to Jakarta Security, ideally with some support and feedback from the MP JWT team · Jakarta Security creates a Lite profile (with just JWT, or maybe some other things suitable for MicroProfile) · MicroProfile can then replace MP JWT with Jakarta Security Lite to unify the API, but doesn't have to, if EE Security Lite spec isn't (yet) good enough to replace MP JWT. MicroProfile would certainly be consulted before EE Security Lite is added to EE Core Profile. All steps here are voluntary and don't require that both MicroProfile and Jakarta EE agree on anything. But with this approach, there are also a lot of options how MP and EE can collaborate to improve the final solution for both. Or am I wrong in how I understand collaboration vs. competition?
All the best, Director, Jakarta EE expert Omnifish OÜ, Narva mnt 5, 10117 Tallinn, Estonia | VAT: EE102487932 Well said, David. I know I feel the same way and before I ask Red Hat engineering to do further work in Jakarta or MicroProfile I want to know whether it's under a collaborative or competitive basis as that will impact where we do such work, if at all.
Sent from my iPhone
> On 10 Nov 2022, at 20:02, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
>
>
>> On Nov 10, 2022, at 11:09 AM, Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>> Good points. There are indeed non-technical differentiators between MircoProfile and Jakarta EE. No one would dispute that.
>>
>> But since we are discussing important philosophical points, let us add the fact that the Eclipse Foundation has always and will always permit competing projects, and that extends to specifications as well. We will never endorse the allocation of a market to one coalition of vendors over another set of vendors. So just because MicroProfile has a specification in a particular domain in no way prevents Jakarta EE from creating a similar spec. That work may or may not be based on prior work done at MicroProfile, so "move" doesn't really factor into the discussion.
>>
>> As you point out, there are important non-technical differences between the two. Any one of those could be a good reason why Jakarta EE may wish to have its own specifications which overlap or compete with MicroProfile specs. In other words, there can be a myriad of reasons why competing specs may occur: business, technical, community, vendor support, etc etc. But "MicroProfile did it first" does not provide it with any sort of veto.
>>
>
> I think these are all very fair points and it's healthy to remind people and have that conversation.
>
> I think it really comes down to if we want to continue to ensure both can live in the same box as many of us have been doing. If we think that's important, then there are some values we would need to maintain.
>
> If we don't want that and do want them to compete, then it might be better for us to explicitly decide that so everyone is fully aware and can plan accordingly.
>
> Given the status quo has been they co-exist in the same box and don't compete, I'd greatly prefer an explicit decision that they will now compete vs slowly making them compete one spec at a time with no explicit conversation or decision that the two will now compete.
>
> Now, I certainly don't always get what I want, but I find if I do my best to make myself at least understood I tend to feel a lot better about the outcome when things don't go my way.
>
> My $0.02
>
>
> -David
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
--
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev |
