[Fwd: Ant buildfiles - best practices for Apache projects]

[Stephen McConnell <mc...@apache.org>]

Recently posted on the community@ list.
An interesting read in the light of our immediate activities concerning 
releases.

Cheers, Steve.


-------- Original Message --------
Subject: Ant buildfiles - best practices for Apache projects
Date: Tue, 04 Feb 2003 22:58:40 +0100
From: Joerg Pietschmann <pi...@apache.org>
Reply-To: community@apache.org
To: community@apache.org



Hi,

I think its time to get gather some "best practices" for setting up Ant
buildfiles.

Let me start with a story. I thought I'll download the Tomcat 4.1.18
source distro and compile it, just for fun.  The fun ended abruptly
after unpacking and calling ant, The build process spwed a lot a
unhelpful flag settings, then aborted because there was no servlet.jar
to copy.  Ok, this was to expect, get a servlet.jar and drop it into the
lib directory.

Didn't work. Ok, there is a build.properties.samples.  Copied to it
build.properties and changed the base.path property. Restarted ant.

The build still bombs, now because commons-collections.jar was missing.

Ok, downloaded jakarta-comons-collections-2.0-src (a sub-sub-project?)
(yes I now there is a 2.1), unpacked and started ant there.  Bombs,
because Junit is missing. Makeing "test" the default target is a bit
odd, but so what. Ant -projecthelp reveals there is a "build"
target. Start "ant.sh buld".  Unfortunately, this compiles the source
but doesn't build a jar. Well, "ant.sh dist" fixed this, but seems to be
a bit of overkill.

Back to the tomcat build. The Collections jar is still not found: the
sample properties expects it in commons-collections-2.0, the Collections
source distro unpacks to commons-collections-2.0-src.  This src suffx is
*annoying*. Deleted it. Still no success. The jar is expected in
${commons-collections.home} but actually resides in
${commons-collections.home}/dist after the dist build. Fixed this too.

Next bomb: commons-beanutils.jar is missing. Downloaded and unpacked
commons-beanutils and started ant. Result: a slew of errors because
collections and logging were not found. In contrast to Tomcat, beanutils
expects collections by default in ../collections/dist, if the samples
properties were used.

At this point I decided to write this message. Note that this is
unrelated to Stefano's rant here:
   http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104428772907971&w=2

Another story with similar experiences regarding excalibur is here:
   http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102382875622031&w=2

Ok so far. The question is: Why doesn't it Just Work (TM)?

Let's view it from another angle. The Unix/C/Make/GNU folks have
developed a set of rules and tools to cope with complex dependencies, to
some extent. There are somewhat reasonable, well known defaults for
locations of libraries and whole packages. Well, the Java world lacks
this, thanks Sun, and instead of DLL and .so hell we got Jar hell. Ok,
no further discussion about this part of the problem.

Then there is make(1) and the associated GNU tools: autoconf, automake,
libtool. There are default targets in makefiles with a reasonably well
defined semantics, you can be fairly sure that "all" is default and that
"make all" will produce executables ready to run (with a few
exceptions), and that there are "install", "clean" and a few others
(unfortunately, the "uninstall" target is not necessarily properly
implemented, if at all). Also, "./configure" is quite good to adapt the
package to the environment, and usually you'll get fairly good messages
if mandatory packages are missing. Automake makes it reasonably easy to
provide makefiles compatible with autoconf and adhering to the
standards.

Back to Jakarta, and Apache Java projects in general. Building an
infrastructure of reusable libraries is a laudable goal. However, I'm
not going to download packages piecemeal, figure out how to configure
each package individually, and actually do this manually.

Now, how should this problem be tackled? Some requirements which come
readily to mind:
- The default buildfile target should inform the user about missing
   mandatory configuration data (properties pointing to various stuff).
- The buildfile should alert the user if mandatory libraries cannot be
   found through the configured properties, rather than dumping errors
   during compilation.
- There should be verbose hints relating configuration properties to the
   packages.

Gump might already help here with the dependencies. We might need an
equivalent for autoconf. I have a huge bunch of other ideas I will
publish later, partially because I want to hear unbiased comments
first. If there is some resonance to this post, I'll setup a Wiki page
(suggestions for a name? substructure?) for publishing upcoming ideas.

J.Pietschmann


---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org





-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net



---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org