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 <vl...@apache.org> 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: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > -- Thiago --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
