My biggest fear is hitting something that is outside of the purview of EE4J and the Eclipse Foundation.
For example I had a play with updating Grizzly to the Jakarta namespace, unfortunately it also ships with an implementation of the OSGI HTTP Service which uses Servlet in the javax namespace!
From: glassfish-dev-bounces@xxxxxxxxxxx <glassfish-dev-bounces@xxxxxxxxxxx>
On Behalf Of arjan tijms
Sent: 06 April 2020 16:51
To: glassfish developer discussions <glassfish-dev@xxxxxxxxxxx>
Subject: Re: [glassfish-dev] A bit of an update on GlassFish 6.0
Hi,
I hear you. I can at least help by prioritising the JSP impl, so I'll try to put that one out tomorrow.
We can do that on the glassfish side for tests.
Problem at the moment where we are blocked we can’t even get compilation working. I could bring in both javax and jakarta dependencies but that to me seems to be a recipe for disaster
in missing changes. My approach currently is change the api dependency, see what breaks compilation, fix and rebuild. However each time I’ve done that I’ve become blocked on an SPI or something from an upstream implementation. For example Weld SPI exposes
javax.transaction. Servlet implementation references JSPC so we need it in the Jakarta namespace.
Steve
Hi,
There's a couple of implementations available, like Mojarra and Soteria. However, these have completely not been tested, as they need, for instance, the Servlet implementation in
the Jakarta namespace.
Probably to get the work going, we should as Steve suggested before, start committing things in master and ignoring the tests for now. They'll all fail for a while then.
When everything is in place, we can look at fixing the tests wherever they fail. This is not a "nice" approach though, but might be the fastest way to move this forward.
In order to do so, we must disable the tests, and only rely on the build passing (which includes some minimal amount of testing).
Hi,
On 4/6/20 4:39 PM, Steve Millidge (Payara) wrote:
> To summarise when trying to move GlassFish to the jakarta namespace we
> are becoming blocked on upstream implementation projects. We aren’t
> committers on a large number of these projects so can’t make RC
> releases. Does anybody know how we can track when these projects make an
> RC release?
probably not exactly what you are looking for but some jenkins job
creating a PR against glassfish repo or sending heads up email to some
list/people built around 'mvn -U -C versions:display-property-updates
-Pstaging' could do the trick. At least this is something I have in
couple of projects and it works well in protecting projects against
human forgetfulness.
thanks,
--lukas
>
> Steve Millidge
>
> Payara
>
>
> _______________________________________________
> 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://www.eclipse.org/mailman/listinfo/glassfish-dev
|
