+1 Markus!
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
|
