tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Shemansky" <>
Subject Re: Mavenization (M10N) of Tomcat Build Process - Should Tomcat Be Migrated to Maven 2?
Date Thu, 18 Oct 2007 21:30:52 GMT
On 10/17/07, Mark Thomas <> wrote:
> Paul Shemansky wrote:
> > Key features that may be useful to us are :
> >
> > - The Standard Directory Layout - Specifically, multi-module builds.
> > This might make managing individual components easier for catalina,
> > coyote, naming, jsp/servlet api/implementation, connector, etc.
> "might" isn't a compelling argument.

I agree that "might" is too passive.  However, by saying "will", I
immediately seem aggressive, paint myself into a corner, prepare for a
Maven vs. Ant flame war, and wind up with no choice but to shoot
myself in the face :)  It "would" make things easier if each of the
components were being managed by separate, designated groups of
developers.  I am now aware that this is not the case for Tomcat, but
I am still motivated to promote 'slight' layout modifications which
may make any potential new developers feel right at home the day they
sign on :
Hello Mark, our project uses this layout :

Of course, if that is not appealing to anyone, we could just create
documentation on how the current version is structured, leaving
nothing to the imagination.  If the Maven layout is shot down, I would
still be willing to help with writing more extensive documentation of
Tomcat's directory structure and build process.  Before I attempt to
contribute any real code, I feel it is vital to become heavily aware
of the build.

> > - Model-Based builds - Automatic packaging for the individual modules.
> Our build script does this.

I didn't say that it didn't.  The current build process is not flawed;
It works very well.  This was only to state that "if" we decided to
modularize, packaging would be a more automated feature which is
wrapped in the definition (pom.xml) of each module, rather than being
intertwined into a single large sequential build file.

> > - Dependency Management - Whether it is Apache or another third-party,
> > dependencies can all easily be plugged in.
> There are only a few and they are easily managed with the current
> build process.

Again, this is not an attack against the current build process.  Ant
is not my enemy.  I am simply proposing that Maven can provide
improvements over how dependencies are managed, now and in the future.
 Perhaps as Filip mentioned, Ivy will accommodate all of the
dependency management via Ant.  I was simply stating that dependency
management is built into Maven, along with a few other features which
IMHO 'may' be nice for the Tomcat build.  As a new programmer to
Tomcat, I feel it would have been nice to see a dependency list or
report 'before' I actually built the project, without having to read
too much into the build.xml.  Dependencies are also currently
downloaded into a project-defined directory. This is opposed to simply
being declared in the build as dependencies and managed in a local
Maven repository which houses dependencies in a clearly defined,
unified directory layout.  In a perfect world, we would not need to
store more than one copy of any of the Commons JAR files on our
machines. IMHO, I think that Maven 2 does in fact help to promote

I am still exploring the current Tomcat build, and again, I apologize
for not being here long enough to know every single thing about the
dependencies involved.  Filip cleared up my initial dependency (DBCP)
issue (thanks again).  But, can anyone tell me why we are downloading
the tomcat-native zip file from the archive url when it seems that it
is already part of the initial Tomcat check-out under the "native"
directory?  Is this a dependency, or part of the project already?

> > - Distribution Management - Packaging and Deployment - Although Tomcat
> > has a structured distribution model with Ant, Maven could make this
> > easier with its assembly plugin.  This also allows outside entities to
> > easily embed specific Tomcat components or customize the server to
> > suit their needs, (i.e. containers like Geronimo and JBoss, IDE
> > plugins for Eclipse or Tomcat.)
> Easier how?

Filip, mentioned that he added the poms to the project so that the
individual dependencies may be publicly distributed into the main
Maven repository.  This, if maintained, can allow any outside vendor
to quickly download all of the latest 'required' components of Tomcat
into their own Maven (or Ant w/ Maven Tasks ;) build process.  They
could easily wrap anything they want around the web container simply
by including Tomcat as a dependency.  This can be attractive,
especially from a software consulting perspective, in which I may want
to have a web application with an easily-accessible-via-build,
"embedded" version of Tomcat.  I believe Jetty actually accomplishes
this, but I like Tomcat better, and this is why I am here. :)

Instead of having to visit and re-download the binary distributions, a
consultant may be able to just add :


Then, essentially, the Tomcat installation process can become a part
of the customer application's build process.  The build process could
incorporate the server, and automatically deploy with the resulting
application (java myProjectWhichContainsTomcat.jar).  I think this may
be nice to have in some cases, but hey I am only one guy. :)

> > - Project Site and Report Generation. - The Tomcat documentation site
> > may benefit greatly, but the Maven reporting plugins seem to be the
> > bigger win here.
> "May" isn't compelling. What reporting? What do we get that we want to
> get don't currently?

Again, "may" is passive, and I used it for that reason alone.  The
site generation phase of the build process would be centrally managed
from the pom.xml, and this would automatically wrap up some of the
basic (DOAP) project information currently maintained elsewhere (i.e.
SVN info, javadocs, mailing lists, issue tracking info, etc.).  After
that you would also be able to have test results, code coverage
reports, PMD code reviews, documentation-checking reports, todo lists
generated from commented source code.  We also open the door for the
ability to build (and/or receive) any reporting plugins that we (or
the user community) think Tomcat should be responsible for (i.e. site
statistics, downloads, users / supporters, etc., possibly even
automated benchmarking results or comparisons to other containers.).
All of this reporting would be immediately available on the Tomcat
project's site.

Although these are not filled with as much data as I would like, these
are examples of what Maven can generate :

Project Info :
Project Reports

When generated, I would immediately know that out of the 898 dev-list
subscribers, the actual team-list like the one found at is much shorter.  This would
show who is 'actively' developing Tomcat, eliminating lurkers, and
providing relevant information about these members.  Provided I don't
aggravate too many of you with this Maven 2 "gobbledy-gook", I'd like
to some day make it to that list, too. :)

> > Whether you vote Yes or No, I am still happy to be working
> > with you. :)
> Overall -1. I just don't see the point. The current process is nice
> and simple and works. If it ain't broke...
> Mark

I know it's not broke, otherwise I wouldn't be using Tomcat as much as
I do.  But, I proposed this merely to find out if there is room for
improvement, though.  Ant and Maven can co-exist using the best
features of both....can we all just get along? :)   More
importantly... can I assimilate you into a "+1, but only if ____
happens" vote, instead?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message