tags:

views:

40

answers:

2

By specifying "-lib foo.jar" to ant I get the behaviour that the classes in foo.jar is added to the ant classloader and are available for various tasks taking a class name argument.

I'd like to be able to specify the same behaviour but only from inside build.xml (so we can do this on a vanilla ant).

For taskdefs we have functioning code looking like:

<taskdef resource="net/sf/antcontrib/antlib.xml" description="for/foreach tasks">
    <classpath>
        <pathelement location="${active.workspace}/ant-contrib-1.X/lib/ant-contrib.jar" />
    </classpath>
</taskdef>

where the definition is completely provided from the ant-contrib.jar listed.

What is the equivalent mechanism for the "global" ant classpath?

(I have thought out that this is the way to get <javac> use ecj-3.5.jar to compile with on a JRE - http://stackoverflow.com/questions/2364006/specifying-the-eclipse-compiler-completely-from-within-build-xml - in a way compatible with ant 1.7. Better suggestions are welcome :)


EDIT: It appears that the about-to-be-released version 1.0 of ant4eclipse includes ecj. This does not answer the question, but may solve my basic problem.

+1  A: 

I've posted an answer to the question that you've linked. I'll repeat a general solution here.

Reading Running Ant via Java, I think you can write a simple wrapper that will properly set a classpath and add any 3rd party library to the resulting class path.

Here I'm just cutting and pasting the sample from the above link with addition of the library to the classpath:

<java
        classname="org.apache.tools.ant.launch.Launcher"
        fork="true"
        failonerror="true"
        dir="${sub.builddir}"
        timeout="4000000"
        taskname="startAnt"
>
    <classpath>
        <pathelement location="${ant.home}/lib/ant-launcher.jar"/>
        <pathelement location="/path/to/3rd-party-lib.jar"/>
    </classpath>
    <arg value="-buildfile"/>
    <arg file="${sub.buildfile}"/>
    <arg value="-Dthis=this"/>
    <arg value="-Dthat=that"/>
    <arg value="-Dbasedir=${sub.builddir}"/>
    <arg value="-Dthe.other=the.other"/>
    <arg value="${sub.target}"/>
</java>

I think you can even reuse the same build file by referencing ${ant.file}, just give a different target as an entry point.

EDIT

I think, this solution should only be used as a last resort measure. If task in general supports a <classpath> tag, then add required libraries locally to that specific task. Your gave a perfect example of this in your question with an ant-contrib taskdef.

Alexander Pogrebnyak
So what you suggest is basically relaunching ant with a "-lib foo.jar" argument? I agree that should be a last resort measure - and I'd like a "just add this to the current classpath" method
Thorbjørn Ravn Andersen
@Thorbjørn. If the task that you are relying on cannot find required library on a current classpath, and does not provide an extension to specify it for the current task only, then this method is as good as any. I read through the linked document and it does not mention anywhere that there is an extension capability that you are asking for. Maybe it's something to request for Ant 1.9. I do think that build files should be self-contained, not relying on global `lib`, or user `lib` directories.
Alexander Pogrebnyak
I will be carrying the jar file along with build.xml resulting in a relative path. It is just a matter of having it loaded.
Thorbjørn Ravn Andersen
+1  A: 

Hi, if you ever decide to move to Ant 1.8 you can use following construction:

<import>
  <javaresource name="resource_name.xml">
   <classpath location="path_to_jar.jar" />
  </javaresource>
</import>  
Denis