Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <013201c065c2$bba86510$3512a8c0@wspunkytse>
Reply-To: "Punky Tse" <punkytse@yahoo.com>
From: "Punky Tse" <punkytse@yahoo.com>
To: <tomcat-dev@jakarta.apache.org>
References: <B65DD694.6794%pier@betaversion.org>
Subject: Re: [tomcat-4.0] building is hard
Date: Thu, 14 Dec 2000 19:41:00 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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" <pier@betaversion.org>
To: <tomcat-dev@jakarta.apache.org>
Sent: Thursday, December 14, 2000 5:44 PM
Subject: Re: [tomcat-4.0] building is hard


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