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