Hi,
Craig and Pier: Let's fix it! We have a beautiful build tool (Ant) ,
why can't we have a good build system?
My build scripts for 3.2 and 3.3 runs great. So, I try to write build
script for TC4. But I failed. Like Jon, I found that it is too hard to
build.
Still, I haven't try Tomcat 4.0. Although I can download snapshot or
milestone build, I like "do it myself"! ;-)
I hope to see that it can be built by myself very soon!
Punky
----- Original Message -----
From: "Pier P. Fumagalli" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 14, 2000 5:44 PM
Subject: Re: [tomcat-4.0] building is hard
> Stuart Roebuck <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]>
> --------------------------------------------------------------------------
--
>
