On 09/10/17 09:31, Huxing Zhang wrote: > Maven has another advantage that it provides a centralized repository for > dependencies, which can be easily mirrored. > The current build process for Tomcat requires different repositories such as: > - apache.org(mirrors available) > - archive.apache.org(mirrors unavailable, access unstable) > - maven repo(mirrors available) > - sourceforge.net (mirrors available, access unstable)
The location of the dependencies and the choice of build system are independent. If any of the dependencies are causing problems we can look at potential alternative locations. We don't have to change the build system to do that. Mark > > which makes it incredibly slow for a clean build of tomcat in countries like > China, making new comers difficult to start. > ------------------------------------------------------------------ > Mark Thomas <ma...@apache.org> > 2017 Oct 6 (Fri) 16:18 > Tomcat Developers List <dev@tomcat.apache.org> > Java 9, modularisation and build systems > > > 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. > > > 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. > > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
