Jon,
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 directory.
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 distributable).
Stuart.
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 [EMAIL PROTECTED]
Lead Developer Mac OS X, Java, XML, etc.
ADOLOS http://www.adolos.com/
