ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wolfgang Häfelinger <>
Subject Re: ApacheCon Presentation
Date Wed, 14 Nov 2007 16:28:40 GMT

I'm missing the 'download' part in the example you gave. It appears that 
you expect your
jars already to be present in ${commons.dir}, and even in a nicely 
structured way. To
much too assume. It should all be handled by Ant's core ..


Wolfgang Häfelinger
Research & Architecture | Dir.
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. +31 (0)70 340 4931

"Peter Reilly" <> 
14-11-2007 16:51
Please respond to
"Ant Developers List" <>

"Ant Developers List" <>

Re: ApacheCon Presentation

On Nov 14, 2007 3:18 PM, Dominique Devienne <> wrote:
> On Nov 14, 2007 8:07 AM, Wolfgang Häfelinger <> 
> > * Simple all third-party jars in $ANT_HOME/lib
> >
> > Honestly, putting something into Ant's  lib directory is really ugly 
and all
> > those alternatives ($HOME/.ant etc) do not solve the overall problem.
> If the project you checkout includes its own Ant extensions, and you
> want to use a stock Ant release, you still have the option of using
> the -lib command line switch to tell the Ant launcher to use your
> custom libs. Using -lib is just as effective as putting the jars in
> $ANT_HOME/lib I believe. Then you only need a little wrapper
> build.bat/.sh script (checked in) to launch Ant properly configured
> for the projects.

I would argue that using -lib is nearly as ugly as placing jars in 
(but not as bad!!)

On projects at work,  that I am involved in, I insist on
using "clean room" ant 1.7.0 and "clean room" java 1.5.* (or higher).

For each antlib / extension that is needed, I have an ant file that
sets up the extension for-example ant-contrib.

<project name="ant-contrib.setup">
  <typedef uri="antlib:net.sf.antcontrib"
      <fileset dir="${commons.dir}/lib/ant/ant-contrib" includes="*.jar"/>

These setup files are called from a setup.xml:
<project name="ant.setup">

  <!-- allow developer override of properties -->
  <property file=""/>

  <property name="java.ver" value="1.5"/>

  <property environment="env"/>
  <dirname property="ant.setup.dir" file="${ant.file.ant.setup}"/>

  <property name="commons.dir"
  <property name="top.dir"

  <property name="dist.dir"

  <property name="" location="src/main/java"/>
  <property name="" location="src/test/java"/>

  <import file="ant-classloader.xml"/>
  <import file="ant-contrib.xml"/>
  <import file="log4j.xml"/>
  <import file="beanshell.xml"/>
  <import file="macros.xml"/>
  <import file="cobertura.xml"/>
  <import file="checkstyle.xml"/>
  <import file="javadoc.xml"/>
  <import file="axis.xml"/>
  <import file="targets.xml"/>
  <import file="findbugs.xml"/>
  <import file="pmd.xml"/>
  <import file="jaxb.xml"/>

Where necessary I use the {antlib:net.jtools.classloadertask}classloader 
( to
shovel jars into the project classloader - necessary for example to
use beanshell
with bsf on ant 1.7.0.  I also found in necessary to use it to avoid
classloading issues
with coverage tools on axis tasks.

<project name="beanshell"

  <!-- Enable beanshell
       With ant 1.7.0 the only way to do this
       within a project is to use cl:classloader
  <cl:classloader loader="project">
      <fileset dir="${commons.dir}/lib/main/commons-logging" 
      <fileset dir="${commons.dir}/lib/ant/bsf" includes="*.jar"/>
      <fileset dir="${commons.dir}/lib/ant/beanshell" includes="*.jar"/>


> Sure, auto-download of dependencies would be nice, and with Ivy part
> of the Ant family, it may come sooner rather than later, but in the
> mean time, -lib is a very effective and easy way to work around your
> issue it sounds like. --DD
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message