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
