Re: javax.servlet -> jakarta.servlet

Hello, everyone!

I first proposed trying to find some way to have the same sources
generating both javax and jakarta versions of the Tapestry
projects/artifacts/JARs that actually use them (don't forget about
Tapestry-IoC, Plastic, Commons, tapestry-json, etc, which wouldn't be
touched, since they don't have Servlet API dependencies and we should
avoid creating new artifacts for them). If we can find a way of doing
that, that's the ideal solution. I was thinking about how we could do
it and I reached a dead end, not finding a good solution for
implementing that. If the very talented Tapestry team manages to do
it, I'll be very happy to be proven wrong. :) Of course, anything I
can help, I'll do it, also very happily.

Thanks Volker for starting the work on this!

On Tue, Apr 11, 2023 at 5:07 PM Volker Lamp <[email protected]> wrote:
>
> Hi David
>
> > A gradle plugin is not a bad idea and would be relatively
> > straightforward to implement. We have developed many gradle plugins over
> > the years and are open to contributing to that effort.
>
> Excellent. Help is always welcome.
>
> > The simplest approach might be to create a task that filters the source
> > tree in place as a separate gradle step. If the sources are updated in
> > place, a cleanup mechanism will be needed to restore the working copy to
> > its unmodified state between builds. Internally we use the Team City
> > swabra plugin to accomplish that goal.
>
> I agree. A temporary copy of the sources should be created, leaving the original sources untouched. The copy mechanism would replace the 'javax' package names with their 'jakarta' equivalents. The target directory of that operation would either be somewhere within the build directory (so that it would be captured by the regular 'clean' task) or in a separate source directory, next to 'src' (in which case the clean task would have to be extended to capture that directory).
>
> As far as the Gradle build script is concerned, we could take the same approach, i.e. creating a copy of build.gradle with the dependencies replaced accordingly, and subsequently triggering another build (not sure if there is a way in Gradle to invoke another gradle build from within a build?) Alternatively, we'd have to enhance the existing build.gradle with logic for the jakarta-ee-9 compatible sources. If we do the latter it is probably a good idea to leverage some of the newer Gradle DSL features in order to break up the build logic in smaller bites that would be easier to digest.
>
> As far as collaboration is concerned, I've just created a branch named TAP5-2741. Feel free to issue pull requests against it.
>
> Thank you,
>
> Volker
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>


-- 
Thiago