You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2017/10/06 08:18:51 UTC
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Java 9, modularisation and build systems
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 6/10/2017 à 13:10, Martin Grigorov a écrit :
> 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.
+1, the standardized project structure brought by Maven makes it easy
for newcomers to jump into the project. Gradle builds tend to be just as
messy as the Ant ones.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Java 9, modularisation and build systems
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Fri, Oct 6, 2017 at 11:45 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hi Mark,
>
> few comments inline
>
> 2017-10-06 10:18 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
> > 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: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
Re: Java 9, modularisation and build systems
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Mark,
few comments inline
2017-10-06 10:18 GMT+02:00 Mark Thomas <ma...@apache.org>:
> 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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Java 9, modularisation and build systems
Posted by Henri Gomez <he...@gmail.com>.
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 <re...@apache.org>:
> On Mon, Oct 9, 2017 at 10:23 AM, Mark Thomas <ma...@apache.org> wrote:
>
> > 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.
> >
>
> 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
> >
> >
>
Re: Java 9, modularisation and build systems
Posted by Rémy Maucherat <re...@apache.org>.
On Mon, Oct 9, 2017 at 10:23 AM, Mark Thomas <ma...@apache.org> wrote:
> 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.
>
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
>
>
Re: Java 9, modularisation and build systems
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 9/10/2017 à 10:23, Mark Thomas a écrit :
> - Back-ports would become more difficult unless all currently supported
> versions were also back-ported (which increases the costs of
> transition)
This is an important point. Maybe the older versions of Tomcat could
just adopt the new source layout (<module>/src/main/java) but keep Ant
as the build system. Thus, the patches could be backported without
changing the paths.
> - If we change the layout of the currently supported versions, that will
> create costs for downstream packagers
As far as Debian is concerned, switching to Maven shouldn't be that
disruptive, the tool is well supported now. Ubuntu folks on the other
hand may be less happy because they didn't include Maven in their main
repository yet, unlike Tomcat and Ant. Changing the build system would
force them to officially support Maven, which isn't a bad thing in 2017
anyway.
> - We'd need to write a code-signing plug-in for Maven
I did write a code-signing plug-in for Maven, maybe it could be extended
to work with the Symantec service used by Tomcat?
https://ebourg.github.io/jsign/
> - We'd need to write a plug-in to use NSIS or continue to use Ant for
> the Windows Installer
No need to write a plug-in for this I think, NSIS could be invoked with
the maven-antrun-plugin.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Java 9, modularisation and build systems
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Java 9, modularisation and build systems
Posted by Rémy Maucherat <re...@apache.org>.
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.
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.
Rémy
Re: Java 9, modularisation and build systems
Posted by Mark Thomas <ma...@apache.org>.
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 <de...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Java 9, modularisation and build systems
Posted by Huxing Zhang <hu...@alibaba-inc.com>.
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)
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 <de...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org