tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Roebuck <>
Subject Re: [tomcat-4.0] building is hard
Date Thu, 14 Dec 2000 09:26:45 GMT

I *absolutely* agree with the need to make the Tomcat build environment easier to setup. 
The current situation is a *serious* barrier to encouraging wider participation.  There's
no rocket science required at present, but few of us have time to mess about and I for one
gave up at least three times before circumstances forced me to work through the process.

However, I don't know if it's just me, but I really find it frustrating when build environments
depend upon relative file structures extending beyond the filepath of the root project.  Inotherwords,
I totally agree with the idea of having a standard directory structure option, but I would
much prefer that this standard directory structure appear inside of the jakarta-tomcat-4.0

Here are some reasons:

1. Good old programming 'side-effects' - intuitively, you do not expect that changes to directories
outside of the tomcat directory will impact on the building of tomcat.  If you are moving
your tomcat build directory to a new location, you don't want to have to look at readme files
to work out what has to move with the directory at the same time.

2. If the 'jakarta-ant' and 'jakarta-servletapi' directories are full source distributions
and a developer is involved in the ongoing development of one of these projects as well (e.g.
ant) there can be a conflict between the version requirements of Tomcat and the ongoing work
on the latest version of a project it depends upon.  To put it in other words, if you are
working on adding new features to the very latest version of ant you may be working with a
version which is incompatible with the current build of tomcat.  You are therefore forced
to maintain two separate copies of ant - one to make tomcat work, one for ant development.

My preference would be to simply include the distributable jar files of required libraries
in a lib/ or similar directory inside the tomcat directory.  Those libraries that are distributable
could be included in the CVS but optionally excluded from the nightly builds and distributions
(to reduce file size).  Users would be asked to place the relevant .jar files of non-distributable
libraries in the same place.  This is basically the model for cocoon - which is *way* simpler
to build than tomcat.  This also makes life a lot easier when moves are made to use newer
versions of libraries for Tomcat, because they can simply be updated in the CVS (if they are


On Thursday, December 14, 2000, at 04:54 AM, Jon Stevens wrote:

> i would just like to point out that setting up an environment to build the 
> java portion of tomcat-4.0 from CVS is WAY to hard. you have to know way to 
> much about where things should go and such. 
> for example, the documentation states that you should point to your JSSE 
> installation directory. given that JSSE instructs you to put things into 
> $JAVA_HOME/lib/ext, the tomcat build system doesn't assume that, it assumes 
> is to be the place where you downloaded and un-tar'ed JSSE. i think that the 
> documentation should be more clear and also the build system should not 
> require you to set a bunch of environment variables if you have a well 
> defined directory structure...keep reading... 
> what i propose is to ask people to either setup their directory structure in 
> a certain way or to set environment variables. 
> for example: 
> /stuff 
>     /jakarta-tomcat-4.0 
>     /jakarta-ant 
>     /jakarta-servletapi 
>     /jsse* 
>     /jmx* 
>     /jndi* 
>     ... 
> Then, Tomcat's build files will first try to find relative paths to the 
> other directories and if it can't find them, it will then look for env 
> variables. I think that this is a perfectly acceptable build system for now. 
> one thing i'm working on right now is adding the above functionality and 
> won't check in my changes until after m5. 
> thanks, 
> -jon 

Stuart Roebuck                        
Lead Developer                                  Mac OS X, Java, XML, etc.
View raw message