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