On Nov 14, 2007 3:18 PM, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On Nov 14, 2007 8:07 AM, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:
> > * Simple fix...place 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 $ANT_HOME/lib
(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"
resource="net/sf/antcontrib/antlib.xml">
<classpath>
<fileset dir="${commons.dir}/lib/ant/ant-contrib" includes="*.jar"/>
</classpath>
</typedef>
</project>
These setup files are called from a setup.xml:
<project name="ant.setup">
<!-- allow developer override of properties -->
<property file="override.properties"/>
<property name="java.ver" value="1.5"/>
<property environment="env"/>
<dirname property="ant.setup.dir" file="${ant.file.ant.setup}"/>
<property name="commons.dir"
location="${ant.setup.dir}/../.."/>
<property name="top.dir"
location="${commons.dir}/.."/>
<property name="dist.dir"
location="${top.dir}/build/dist"/>
<property name="main.java" location="src/main/java"/>
<property name="test.java" 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"/>
</project>
Where necessary I use the {antlib:net.jtools.classloadertask}classloader task
(http://enitsys.sourceforge.net/ant-classloadertask/) 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"
xmlns:cl="antlib:net.jtools.classloadertask"
xmlns:ac="antlib:net.sf.antcontrib">
<!-- 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">
<classpath>
<fileset dir="${commons.dir}/lib/main/commons-logging" includes="*.jar"/>
<fileset dir="${commons.dir}/lib/ant/bsf" includes="*.jar"/>
<fileset dir="${commons.dir}/lib/ant/beanshell" includes="*.jar"/>
</classpath>
</cl:classloader>
</project>
Peter
>
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
