[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [glassfish-dev] Splitting up the jakarta work
|
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.
Kind regards,
Arjan
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$