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
From: Bill Shannon <bill.shannon@xxxxxxxxxx>
Sent: 25 March 2020 02:57
To: glassfish developer discussions <glassfish-dev@xxxxxxxxxxx>; Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Subject: 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$
|