Hi,
On Fri, Oct 6, 2017 at 11:45 AM, Romain Manni-Bucau <[email protected]> wrote: > 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. > Right! Maven also has 'mvnw' script (Maven Wrapper) that allows to bootstrap it with a predefined version. For example this project uses it https://github.com/sidnan/loopback-rest-connector-example/tree/master/DemoBCH And quite robust https://maven.apache.org/plugins/maven-antrun-plugin/ But also take into account the IDE support. In Intellij IDEA at least the Maven support is much better than the one for Gradle! I personally prefer Maven because it is more consistent. With free-style build tools like Ant, Gradle, sbt one has to invest some time to understand the build and be able to make changes. My 2c. Regards, Martin > > > > > > > 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] > > > > >
