macrodef'd <jar> task not behaving like an implicit fileset?
Using standard Ant 1.9.7 to assemble a bunch of jar files. We've made a macro to help cut down on the verbosity of the XML:
<!-- All 'description' bits snipped for SO posting. -->
<macrodef name="buildjar">
... bunch of <attribute> ...
<element name="also"/>
<sequential>
<jar ....>
<manifest> ... </manifest>
<fileset what="stuff in every jar file" />
<fileset what="and this stuff too" />
<mappedresources if:true="beauty">
<fileset for when truth is beauty/>
<globmapper from="ugly" to="beauty"/>
</mappedresoruces>
<!-- Anything else for this specific jar. -->
<also/>
</jar>
</sequential>
</macrodef>
This works:
<buildjar .........>
<also>
<fileset file="/some/path/somewhere/a_single_file"/>
</also>
</buildjar>
But this does not:
<buildjar .........>
<also>
<include name="/some/path/somewhere/a_single_file"/>
</also>
</buildjar>
There are no errors. Looking at ant -d output, there's no mention of the additional entry at all, where in the first example there is a line for fileset: Setup scanner in dir /some/path/somewhere with patternSet{ includes: [a_single_file] excludes: [] }
Ditto for multiple files. This works:
<buildjar .........>
<also>
<fileset dir="/some/path/somewhere">
<include name="one_file" />
<include name="foo**" />
</fileset>
</also>
</buildjar>
but this does not:
<buildjar .........>
<also>
<include name="/some/path/somewhere/one_file"/>
<include name="/some/path/somewhere/foo**"/>
</also>
</buildjar>
According to the Ant manual's page for <jar> ,
This task forms an implicit FileSet and supports most attributes of <fileset> (dir becomes basedir) as well as the nested <include> , <exclude> and <patternset> elements.
So in theory, shouldn't an <include> simply be enough, and become a nested element of the macro'd <jar> ?
Obviously, in practice this isn't a problem (we slap a bigass comment in the build files telling people to not leave out the explicit <fileset> ). And we can't put the <fileset> into the macro definition like this:
<macrodef name="buildjar">
<element name="also"/>
<sequential>
<jar ....>
.....
<!-- Anything else for this specific jar. -->
>> <fileset dir="some_generic_base_path">
<also/>
>> </fileset>
</jar>
</sequential>
</macrodef>
because then when the calling code does a buildjar without any also blocks, the unrestricted fileset will include the entire some_generic_base_path tree.
Is this simply some interaction between macrodefs and filesets that has taken us by surprise?
Short answer is no - it's not a macrodef problem. To use the implicit fileset you must specify the basedir attribute for the <jar> task. Here's an example that illustrates this:
<jar destfile="my.jar">
<include name="a/b" />
</jar>
<zip destfile="my.zip" >
<include name="a/b" />
</zip>
In the example the <jar> task will succeed and create a manifest-only jar file. But the <zip> task will fail saying:
BUILD FAILED
build.xml:8: basedir attribute must be set, or at least one resource collection must be given!
The jar task is based on the zip task and inherits its check for resources. Because the jar task has some - the manifest - the error is not thrown.
If you want to use the implicit fileset, specify a basedir .
上一篇: 用于优化矢量移位的汇编代码