tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Gomez <henri.go...@gmail.com>
Subject Re: Java 9, modularisation and build systems
Date Mon, 09 Oct 2017 12:51:26 GMT
OMG, Maven for Tomcat, after so many years :)

May be time to resurrect Olivier Lamy works

2017-10-09 14:43 GMT+02:00 Rémy Maucherat <remm@apache.org>:

> On Mon, Oct 9, 2017 at 10:23 AM, Mark Thomas <markt@apache.org> wrote:
>
> > On 06/10/17 13:01, Rémy Maucherat wrote:
> > > On Fri, Oct 6, 2017 at 10:18 AM, Mark Thomas <markt@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.
> >
>
> Yes, if there's a switch to maven, then Tomcat has to become something
> resembling a Maven project (IMO), with a non monolithic source tree. So it
> seems you don't like it any more than before, so then it looks like it's
> still a "no" for maven. Your arguments are reasonable especially for
> maintenance of previous branches.
>
> Poor Maven, he may start being depressed after being rejected so often ;)
>
> Rémy
>
>
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message