Hi,
I'm about to commit new types to cvs, called <path> and <pathelement>. These
types can be used to group a set of files and directories that need to be
passed to an external application as a single command line argument or
environment variable.
For now only the <arg> element of the <exec> task exposes these types.
For example :
Execute a java application using IKVM.NET that requires the Apache FOP jars,
and a set of custom jars.
<path id="fop-classpath">
<pathelement file="${fop.dist.dir}/build/fop.jar" />
<pathelement file="${fop.dist.dir}/lib/xercesImpl-2.2.1.jar" />
<pathelement
file="${fop.dist.dir}/lib/avalon-framework-cvs-20020806.jar" />
<pathelement file="${fop.dist.dir}/lib/batik.jar" />
</path>
<exec program="ikvm.exe" useruntimeengine="true">
<arg value="-cp" />
<arg>
<path>
<pathelement dir="conf" />
<path refid="fop-classpath" />
<pathelement file="lib/mylib.jar" />
<pathelement file="lib/otherlib.zip" />
</path>
</arg>
<arg value="org.me.MyProg" />
</exec>
The implementation and behaviour closes matches that of the Ant <path> and
<arg> elements, with these differences :
- Ant's <path> type has a single "location" attribute, while our <path> type
has split this up in separate "file" and "dir" attributes.
- Ant's <path> type has shortcut "path" and "location" attributes, so you
can do :
<path location="afile.txt" />
instead of
<path>
<pathelement location="afile.txt" />
</path>
- Ant's <arg> element allows a reference to an existing <path> definition to
be specified using a "pathref" attribute on <arg>, while we do not allow
this.
<arg pathref="fop-classpath" />
Is this something we should support ? I'd like to avoid this, if its
not really necessary.
- Our <arg> element allows a <path> to be defined inline, while Ant only
allow a reference to an existing <path> definition to be set.
<arg>
<path refid="fop-classpath" />
</arg>
or
<arg>
<path>
<pathelement file="afile.txt" />
</path>
</arg>
- Ant's <path> element also allow a nested <fileset>, <filelist> and
<dirset>, while we do not. Support for nested fileset's could be
interesting.
The <path> type is also exposed by the <env> element, however that <env>
element itself is not yet exposed to build authors. Right now, the <option>
element is used to specify environment variables that should be set when
lauching an external process (using the <exec> task) :
<exec program="..">
<environment>
<option name="..." value="..." />
</environment>
</exec>
That <option> element just uses the specified value as is. Meaning, it does
not support PATH's, it does not resolve a file name to an absolute path,
.... While this is all support by the <env> element. So, I'd like to
replace the nested <option> element with the <env> element for the
<environment> element, but this would ofcourse be a breaking change.
What do you think ?
Gert
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
