On 06/10/17 13:01, Rémy Maucherat wrote: > On Fri, Oct 6, 2017 at 10:18 AM, Mark Thomas <ma...@apache.org> wrote: > >> The usual candidate for an alternative build system is Maven. The >> argument for Maven is that it is more widely known and hence easier to >> get started with. The argument against is broadly that Maven is very >> opinionated and they way Tomcat currently does things is not consistent >> with what Maven expects and some things (e.g. the Windows installer) are >> well outside the typical Maven build. Therefore switching to Maven would >> require a fair amount of effort. >> >> I'd like to suggest a third alternative: Gradle. The argument for Gradle >> is that it can boot-strap itself so, unlike Ant, a new user doesn't need >> to download the build tool. Gradle can also import Ant build files so we >> could start with a simple Gradle script that simply imported the current >> Ant script and then migrate slowly over time. The argument against is >> that it isn't as widely known as Maven. >> >> >> My own views are neutral at this point on modularisation. I don't have >> any immediate suggestions for changes but I'd like to hear what ideas >> others have. On build systems, I'm not convinced that the benefits of >> switching to Maven justify the costs. Gradle looks promising and I do >> like the boot-strapping feature. If there was consensus to move to >> Gradle, I'd be willing to help that process. >> > On Java 9 modularisation I'm super neutral too. Especially since it > wouldn't bring anything to Tomcat IMO.
For Java 9 modules, I can see some benefits to defining Java 9 modules to be consistent with the names and dependencies we already have. Primarily, if a user adds a module (not using Maven) then they'll get notified about missing dependencies when they try and build it. That is about the only benefit I can see though and it is a fairly small one. > On the build and source structure, I'd say the first decision should be > another yes/no on Maven, since that's what everyone else has been asking > about. Then if it's still a no, we can make another decision on Gradle. I remain unconvinced that the benefits of switching to Maven would justify the costs. The previous experiments have shown that it is not practical to keep the current source code structure and use Maven. See: http://svn.apache.org/viewvc/tomcat/sandbox/trunk-mvn-build It is 6 years old (and for 7.0.24) but you get the idea. Note that: - I had to build and run with Java 7 to avoid various class version issues - It is incomplete (e.g. no Windows Installer build) Benefits: - More widely known, so easier/faster for newcomers to pick up - Standard project structure makes it easier/faster for newcomers to navigate - Producing OSGI bundles would be simpler - Bootstrap wrapper available Costs: - The code would need to be split into multi-modules - Back-ports would become more difficult unless all currently supported versions were also back-ported (which increases the costs of transition) - If we change the layout of the currently supported versions, that will create costs for downstream packagers - We'd need to write a code-signing plug-in for Maven - We'd need to write a plug-in to use NSIS or continue to use Ant for the Windows Installer Overall, I remain firmly unconvinced that a move to Maven is in the best interests of Apache Tomcat. The time that would be required to migrate to Maven would be significant and would disrupt the project for an extended period of time (my expectation is several months). It would also disrupt down-stream users. That is a significant cost. While I don't deny there are potential benefits, those benefits are - in my view - significantly smaller than the associated costs. Another concern is that switching to Maven would not be a small, reversible change. It would be reversible but the effort required, both to make the change and to reverse it, would not be small. I haven't seem any significant movement from the last time we discussed this so I don't think we need a vote or anything. That said, I've no objection to a vote being held if a committer wishes to call one. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
