[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [glassfish-dev] Splitting up the jakarta work
|
Hopefully the owner of each API knows what depends on it, and what
it depends on. Just find something easy and do it. If you try
something and it turns out to be hard, skip it and keep looking for
something easy. Well, easier.
I don't think there's a magic bullet here. We just need to dive in
and do it. And be willing to ix it when we break it.
Steve Millidge (Payara) wrote on
3/25/20 2:00 AM:
Does
anybody know what those things are? I thought that’s what
the waves are? However the early waves are used the most by
the later waves. So it’s not the direct dependencies an api
has it is how many other apis use that jar that is the
important measure. Hence the thought to start in reverse
wave order but as I said I fear that will suck in a lot of
apis.
Steve
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$
_______________________________________________
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!IlYoKi4KctvNsCS2_uYYeVEeMEtcmtWqunUSIJYR_zSDo_lWKrXb7gWVb63dwvTRbg$
