Is there no way to do this with deprecation? That is, repackage the classes, but add whatever is used externally back via extensions or proxies so that users of the old code would work, but get deprecation warnings? If so, it could then be done bottom-up (that is, starting with the projects that don’t reference any renamed jars).
I think this is ok, as long as someone is managing the process and knows what's broken, why it's broken, and who's going to fix it. This is not a "blame game", this is a project management goal to make sure we're always moving forward.Steve, if that's you, then I support this.Steve Millidge (Payara) wrote on 3/27/20 2:51 AM:
I think we will have to accept that master will be broken. Either from a test perspective or from a GlassFish starting perspective. Are we prepared to accept a master where GlassFish just compiles but doesn’t run or pass tests for an interim period until everything is merged in? Steve 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. 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!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$
_______________________________________________
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!JB4QHdm9M5sIKniAcvllGjMM-usE8H0qjOXFQDYEptxRgYZLc4dbwyNU8KMLlNRCnw$
_______________________________________________glassfish-dev mailing listglassfish-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/glassfish-dev__;!!GqivPVa7Brio!MaBkIuuI-TBvEsJrzlayCzQAEpu6GSajY5k1r69pTyrnW-Wf63kEgy_Ujpf3y93PPw$
|