tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pier P. Fumagalli" <p...@betaversion.org>
Subject Re: [tomcat-4.0] building is hard
Date Thu, 14 Dec 2000 09:44:52 GMT
Stuart Roebuck <stuart.roebuck@adolos.co.uk> wrote:

> 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.

Oh, by the way. Despite what I said to Jon (with whom I was discussing right
this week-end about this), I too agree that building Tomcat 4.0 is a major
pain. It took me 1 day to figure out what was needed and so on. I had a chat
with him on that last time we talked on the phone and we agreed that we need
to make it simpler before going beta and final.

Thank you very much Stuart for outlining what were your difficulties trying
to build, when you get used to it, it's really hard to see what are the weak
points in the process...

> 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.

I agree... The most weird thing to see is when you type "./build.sh" and
aparently nothing gets generated, until you don't look in "../build"

> 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.

Right... But also Ant changes behavior of its core components every other
week, it's hard to keep that in sync. I believe it would be good to "freeze"
one version and keep using that.

> 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).

Someone (me! :) proposed to do as they do in XML land with the Xerces
project. They distribute a simple "xerces-tools..." JAR containing all
libraries required for the build. What do you think? Would it be a good idea
to do the same for Tomcat? I'd rather not check in JARs in the CVS, but I
believe that a single big zip with all libraries would be great...

    Pier

-- 
Pier Fumagalli  <http://www.betaversion.org/>  <mailto:pier@betaversion.org>
----------------------------------------------------------------------------



Mime
View raw message