----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "jakarta-commons" <[EMAIL PROTECTED]>
Sent: Sunday, April 01, 2001 2:07 AM
Subject: Re: [PROPOSAL] build structure jakarta-commons
> As I warned Geir I would :-), I've got a different set of preferences for
> build procedures to suggest. Anyone who has followed along on TOMCAT-DEV
> and GENERAL knows that I'm not a fan of checking JAR files in to the
> repositories. Having a common build/lib directory, as Geir suggests
> below, is better than having ant.jar checked into every single Commons
> package, but IMHO it will lead to conflicts over versions of the shared
> JARs (I need Ant 1.3, someone else needs Ant 1.2, and so on).
>
> In addition, what would we do about dependencies between Commons packages
> themselves? After all, reuse is the whole idea? If Rodney's DBCP is
> accepted, that means we need copies of the other three Commons packages he
> depends on (JOCL, Pool, Collections). OK, that means that when I build
> Pool there's a common of commons-pool.jar in my compile classpath unless I
> go to interesting lengths to explicitly exclude it ...
>
> Instead, an approach to build scripts that I'm currently using in Struts
> (and plan to suggest for Tomcat) makes a single assumption about what
> software the developer has installed on their machine -- you must have
> your favorite version of "$ANT_HOME/bin" on your PATH so that the
> "ant" command found there can be executed. Now, you don't need build.bat
> or build.sh scripts, or all the ugly environment variables that go with
> them -- all you do is say things like:
>
> ant clean
>
> To deal with external dependencies, the current build script for Struts
> (and the one I checked in for the beanutils package) uses the ability of
> recent Ants to load configuration properties from properties files
> (and was inspired by the fact that the Ant build.xml itself uses this
> approach), while silently ignoring any such files that don't exist. In
> the case of beanutils, you will see the following at the top of the
> build.xml file:
>
> <property file="build.properties"/>
> <property file="../build.properties"/>
> <property file="${user.home}/.build.properties"/>
>
> which lets the user define a convenient hierarchical set of places to look
> for customizations. Setting things like xerces.home in your user home
> directory lets you share this declaration across all projects, while
> overriding it with a local file
>
> The developer's copy of "build.properties" is *not* checked in to CVS,
> because it is specific to a particular user's environment. However, a
> "build.properties.sample" is checked in to document the configurable
> propeties that this particular package depends on (for beanutils, the
> external dependency is on where you've installed JUnit).
>
> I'm a believer that developers want control over which versions of which
> JAR files they use when building things. Build scripts based on checked
> in JAR files will either disallow us that control, or they will have to
> support the same level of complexity for external dependencies already
> identified. For me, I don't see the value add of having the JAR files
> there.
>
> I'm also aware that lots of projects do in fact check in JARs (how many
> copies of Ant do you have installed on *your* disk? :-). But I would
> prefer that we don't do that.
>
> Craig
>
+1 on all that as this is also my belief and what I have also done in
Cactus.
