[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [glassfish-dev] Splitting up the jakarta work
|
I think we have different ideas of what the bottom is. :-)
Find the things with the fewest dependencies and change them first.
Maybe that's the top? :-)
Steve Millidge (Payara) wrote on
3/24/20 1:56 AM:
Bottom
up would likely be something like Inject but I fear that
will hit almost everything. I was leaning towards top down
but again I think that will likely require a 80% change to
do effectively.
Changing these
in parallel is probably hopeless.
To the extent possible, we should be changing them "bottom
up".
Find the smallest set that you can change, do that, then move
up the dependency tree. There may be places where you're just
stuck doing a whole bunch at once.
arjan tijms wrote on 3/23/20 12:42 PM:
Hi,
Some of the "edge" libs (that don't
depend on other things) are somewhat easier to be done,
but you often do bump in to each other when
changing poms and the implementation code. For instance,
when updating for Jakarta Servlet and updating for
Jakarta Authentication you touch the same classes in
GlassFish (e.g the RealmAdaptor and the code it calls).
Updating of the components (Grizzly,
Jersey, Mojarra, Soteria, ...) is something that's much
easier done in parallel, but not everything is directly
under the GlassFish project.
I'm continuing to look on what causes
the test instabilities.
Yeah
Jenkins seems unstable for testing GlassFish at the
moment.
What’s
your conclusion on how easy it is to do these
library changes in parallel?
Steve
Hi,
In
parallel to this I've spend time updating some
of the dependencies. Unfortunately after
working on Bean Validation, randomly in some
tests GlassFish doesn't fully boot on Eclipse
Jenkins, causing the asadmin start-domain
command to time out.
Debugging
this is hideously difficult due to the
randomness of the hangs.
Same
thing is discussed in this JSON-P PR
integration
https://github.com/eclipse-ee4j/glassfish/pull/22943 where JSON-P
should have a small impact given it is a new
api but it needs an updated Jersey or the
server won’t start.
Steve
Problem
is the code doesn’t compile unless we
potentially go through an implementation
phase when we support two versions of the
library e.g. Jakarta Transactions at the
same time with both javax and Jakarta as
dependencies which means adding the new
dependency in some places then unpicking it
later. Which seems brittle.
For
example I tried to add Jakarta Transactions
as it is needed for Jakarta Connectors. So I
started changing namespace of references to
it in the code base. Unfortunately it is
used in public javax EJB apis so now the
GlassFish EJB code does not implement
javax.ejb interfaces so I need to update EJB
to use Jakarta namespace and so on and so
on…
I’m
tempted to change all namespace in one go
and fix compilation errors but then I
suspect I will also need all the upstream
implementation projects to be ready that are
not part of GlassFish or I suspect the
server won’t start with OSGI errors. Yuk.
Steve
Can
this not be one, one library at a time? That
is, each PR handles the changes for the
library and all of its references, but no
more?
Russ
I
recently started trying to do the
work to integrate Jakarta
connectors namespace change as the
implementation of the api is in
core GlassFish. However to do so I
also had to start doing the work
on Jakarta transactions. Also now
I’ve hit that I also need to do
all the changes for EJB as well or
GlassFish won’t compile. I have a
horrible suspicion that this
change is likely going to suck in
a lot of the apis and hit a huge
chunk of the code base.
Does
anybody have any good ideas on how
to work in parallel on a lot of
this work?
I’m
starting to think that a large
chunk of the work is going to have
to be done in one go in one PR!
Does
anybody have a better idea?
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list,
visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/glassfish-dev__;!!GqivPVa7Brio!KCrJfd9RxFJu3Yvq84Jj8UgY83QDwEKWPYX5Hw-_GeC1B3j0wOFQUWQ7x_RKjmE-7w$
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/glassfish-dev
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/glassfish-dev
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/glassfish-dev__;!!GqivPVa7Brio!KbpRnRElprFfOPngnvy1FHw3eKd9debZMR84vwrZJLdnzse9rMoVRroaHuFCR3KHvg$
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/glassfish-dev__;!!GqivPVa7Brio!OQ4WGJa23rpYcO7lLB3tIvi_NlikXTAJOvEQ6gGNiRw1DJ8pGY--851awvGPy7eq0g$
