Hi Mark, few comments inline
2017-10-06 10:18 GMT+02:00 Mark Thomas <[email protected]>: > Hi all, > > As you have probably seen, I've been working on improving Java 9 > support. The current TODO list is: > > - module path scanning > - handling multi-release JARs in the JarScanner > > I've been looking at the module path scanning and while there are > various approaches, they all make fairly heavy use of Java 9 APIs. > Implementing them via the existing JreCompat approach is going to > require a lot of reflection. That got me thinking about the obvious > alternative: multi-release JARs. > > Handling multi-release JARs is going to require some changes / additions > to the build process and source layout. That reminded me of a comment > that Rémy made at TomcatCon in London regarding modularisation and build > tools and whether we wanted to do things differently. If we want to make > changes in that area it probably makes sense to make them now - hence > this e-mail. > > Modularisation and build tools are inter-related so I think it makes > sense to discuss them together. Hence this thread. > > I'm going to start with what I think is the easy one: Modularisation. > > Tomcat is already modular. You can remove some features (JSP, WebSocket, > clustering?, store-config?) simply by removing the JARs. Do we want to > take this further? Nothing immediately springs to mind hence the fairly > open question: what changes could we implement to make Tomcat more > modular and how would those changes benefit our users? > > The build tools aspect has, historically, been the area where fairly > strong opinions have been expressed. > > The argument against Ant is that it isn't as well known amongst > prospective new contributors as other tools and hence creates a barrier > to contributing that harms the community. The argument for Ant is that > it works, it isn't causing any pain points and it has the flexibility to > handle all aspects of our build. > > 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. > Maven also has this wrapper stuff ( https://github.com/takari/takari-maven-plugin) and an ant plugin so this doesn't help much to decide between gradle and maven IMHO. > > > 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. > > I'm concerned of all consumers of tomcat embedded - none of them are java 9 friendly today AFAIK - including spring boot - so this could create a moment where tomcat can't be used on java 9 even if it supports it by itself ("alone"). Maybe it is the kind of work which can be done in a branch in quick and dirty mode to evaluate the current state before speaking of a build tool which is mainly an implementation detail not impacting much users _immediately_? Rephrased: I would like tomcat to avoid to go live and prevent people to upgrade to get security fixes (or bug fixes) due to java 9 work - it has been the case for surefire where a few release broke more than they helped to support java 9. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
