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
On Sat, 31 Mar 2001, Geir Magnusson Jr. wrote:
>
> I think it would be nice if for the jakarta-commons tree, there is a
> build.sh/build.bat that will invoke the build of every component, and
> further, that the jakarta-commons tree include all the necessary jars to
> build all components completely, except the JDK.
>
> This way, our nightly snapshot is self contained - very convenient for
> first time users as well as those instances where you are on a strange
> machine and need to quickly download and build (which happens to me
> often as a consultant...)
>
> I know we only have one component in the main CVS, but it might be good
> to get this started early .
>
> So what I want to do is make the following
>
> 1) jakarta-commons/build
>
> containing a build.sh/bat/xml set that has a default target that builds
> all the components in one shot. Each component is responsible for
> wiring their build in there. I am hoping all use ant to build, so it
> will be darn easy. (I forget if we 'require' that...) We can make it
> generate a complete javadoc for all the components, a common jar of all
> the components, etc.
>
> 2) jakarta-commons/build/lib
>
> contains common jars used for building. For example, I would start with
> ant.jar, ant-optional.jar, xerces.jar, junit.jar and velocity.jar (for
> using Anakia for documentation generation.) That way each project
> doesn't have to include these, and users don't have to go on an
> easter-egg hunt to find all the parts needed to build.
>
> For those wary of centralized control, the following is not the
> proposition of a requirement :) -> Then each component can have their
> own build/lib with jars that they need. If commonality can be found,
> then we can move them to the top-level build/lib. If a component needs
> a version different than that it the top level, then they can keep their
> own copy w/in their component.
>
> I know there are strong feelings about putting binaries in CVS, but I
> think this would be a good thing. We do this in Velocity, and I think
> it works out.
>
>
> I am happy to do the work. I am looking for alternative suggestions or
> votes of support.
>
> geir
>
>
> <aside>
> I want to note that I think having each component under the same CVS
> tree will be ungainly as we acquire more components. It will be
> important to be able to download individual nightly builds of each
> component, as well as the whole thing...
> </aside>
>
> --
> Geir Magnusson Jr. [EMAIL PROTECTED]
> Developing for the web? See http://jakarta.apache.org/velocity/
>
