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
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
