Dmitry,
all you say is correct, but again, it demonstrates that GlassFish (a product) was the driver to delay JAX-RS (an API). OSGi is not required by the API Java EE. It is solely required by the Eclipse product GlassFish. The "We" in your last sentence is exactly what produces that problem: The PMC is the same for the Eclipse product GlassFish and the cross-vendor standard Jakarta EE. No application vendor outside of Eclipse cares about GlassFish or Eclipse products, so certainly this is an impediment to accept Jakarta EE as a not-Eclipse-specific API.
-Markus
From: ee4j-pmc-bounces@xxxxxxxxxxx [mailto:ee4j-pmc-bounces@xxxxxxxxxxx] On Behalf Of Dmitry Kornilov
Sent: Samstag, 6. April 2019 01:29
To: ee4j-pmc@xxxxxxxxxxx
Subject: Re: [ee4j-pmc] Renaming
OSGi changes were required because it's been decided to change Maven coordinates. I agree that it was not essentially needed because it significantly delayed the GF release. But it was a requirement, not a simple ask of other projects. Dropping OSGi support is a "great" idea. We would not able to release GlassFish at all in this case and it would be a great artificial delay! Remember, we had to release GlassFish to prove that all components are transferred to Eclipse, everything builds and passes TCK.
-- Dmitry
On 05.04.2019 23:12, Markus KARG wrote:
Dmitry,
JAX-RS was asked for changes that were technically not essentially needed , but asked for by Jersey and other teams, in particular support for OSGi: Java EE does not Mention OSGi nor does JAX-RS, but we had been urged to fix it instead of simply dropping it. Wayne explicitly asked us to take care of GlassFish demands in particular, hence Keep our repo untouched until the product GlassFish was published – but GlassFish, again, is just an Eclipse product, not a Jakarta standard. I think you remember this discussion we had back then. None of the issues solved back then had been pure API issues, but actually had been product issues. That’s why I say our products have a clear benefit from being managed under the same PMC as the APIs compared to products of third party vendors.
BTW, I neither see a dramatic time we would need to split the PMCs, nor would I say spending that time before going other steps would be worth it. The API PMCs could be the API spec leads then, the product PMCs could be the product leads. If done pragmatically this could be done within few days.
-Markus
Markus,
I think we all agree with it. I am not sure that we need to do it now though. Sooner we release Jakarta EE 8 -> better. Top project reorganization is time consuming. I don't understand what artificial delays are you talking about. Please clarify.
-- Dmitry
On 05.04.2019 19:52, Markus KARG wrote:
I'm very much +1 for splitting up into Jakarta EE (= only APIs, TCKs, Specs) and EE4J (= only products like Jersey) to clearly tell third party vendors that Jakarta is open for them and there is no preference for Eclipse products. Whether there is time for that or not. It is simply inauthentic for market competitors that e. g. Jersey will not be preferred as long as it stays under the same PMC than JAX-RS, and the long artificial delay we had with JAX-RS due to particularly Jersey requests in the recent GlassFish release proofs that I am right. Standards MUST be independent or they are not really norms but just default choices!
-Markus
Hi,
Just to be clear, it is not Wayne's proposal. The naming standard has been formed after discussions among all the members of the Jakarta EE Working Group Steering Committee and Specification Committee. You are free to come up with your own suggestions, but ultimately the names must be approved by (I would guess) the Specification Committee (maybe also the Steering Committee).
So, to your proposal. EE4J is more than just Jakarta EE. It also contains implementations, such as Jersey. We have discussed splitting out the Jakarta EE projects to its own PMC and the implementations to its own but decided against it to avoid losing more time and introducing another layer of complexity. The topic may come up in the future though.
In case we follow Wayne's proposal to get rid of the "Eclipse Project for" prefix, I'd like to propose to replace the word "EE4J" by "Jakarta", too.
In particular it would be great if the URL of the Github API projects does not read like "…/eclipse-ee4j/…" but "…/jakarta/…" or "…/eclipse/jakarta/…" instead. :-)
According to Wayne it is up to the PMC to decide, so I hereby ask the PMC to decide about that.
-Markus
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc