I have a path as follows:
<path refid="myjarlocation"/>
Now I want to iterate over this path and for each value present in the path I want to call a macrodef with that value as one of the property to be used inside the marcodef.
In case of target we can easily do it as follows:
<foreach target="mytarget" param="jarloc">
<path refid="myjarlocation"/>
</foreach>
I cannot use for each because I need to pass multiple parameters , so I am using macrodef. So, therefore the question how to iterate over a path and call a macrodef instead of a target.
I've made something similar work by using ant-contrib's for task to iterate a path and passing the path element along to a macrodef.
First get ant-contrib in your project - see http://ant-contrib.sourceforge.net/
Next, define your macrodef in your ant build however you want including some attribute that will take your path element. eg:
<macrodef name="awesome-macro">
<attribute name="path-to-deal-with"/>
<attribute name="unrelated-attribute"/>
<sequential>
...
</sequential>
</macrodef>
Then, use the for task to iterate the path into pathelements and invoke the macro:
<for param="path.element">
<fileset dir="${jars.dir}">
<include name="*.jar"/>
</fileset>
<sequential>
<awesome-macro path-to-deal-with="#{path.element}" unrelated-attribute="whatever"/>
</sequential>
</for>
Note the use of #{path.element} as opposed to ${path.element} inside the for loop to refer to the looping parameter!
Related
I am working on ant script and I am defining two param but script says you have already defined the param.Can yopu define how could I define two param in for loop in ant script.
<project name="tomcat_win_deploy" basedir="." default="usage">
<!--taskdef resource="net/sf/antcontrib/antcontrib.properties"/-->
<taskdef resource="net/sf/antcontrib/antlib.xml"/>
<target name="env.copy.local.props">
<for param="host" list="${deploy.host}" param="path" list="${deploy.path}">
<sequential>
<copy todir="\\#{host}\${deploy.path}\conf\"
file="Properties/${deploy.env}/local_for_test.properties"
overwrite="true"/>
</sequential>
</for>
</target>
</project>
One way might be to define a list of delimited property pairs and process that in a loop, splitting each property into its two values.
So instead of having separate host and path lists:
hosts=a,b,c
paths=/a/,/b/,/c/
you might have a single host_path list:
host_path=a /a/, b /b/, c /c/
The trick then would be how to split variables and use them in the loop (and not running into the ant "properties are immutable" feature).
This answer shows how you could use the Ant Flaka addon to achieve exactly that.
I have the following target in my build file:
<target name="copyLibrary">
<copy toDir="${workingDir}/${location}" includeEmptyDirs="false">
<fileset dir="${librariesRoot}/${libraryDir}" includes="*"/>
</copy>
</target>
What I want to do is check the value of ${libraryDir} and if it is a particular directory, do not perform the copy.
I have tried to change the fileset to use nested include and exclude tags but it doesn't like this. I have also tried to add an unless attribute to the target and copy, but these are not allowed. I am currently working on the if attribute on the target to see where I get. I have a feeling that I will probably need to change from a fileset to something like a dirset.
A <fileset> can have nested <include> and <exclude> elements. These <include> and <exclude> elements can have if and unless attributes.
In your case, an <include> with an unless may work:
<condition property="libraryDir-is-scorned">
<equals arg1="${libraryDir}" arg2="unlovedLibrary"/>
</condition>
<copy toDir="${workingDir}/${location}" includeEmptyDirs="false">
<fileset dir="${librariesRoot}/${libraryDir}">
<include name="*" unless="libraryDir-is-scorned"/>
</fileset>
</copy>
I think this may be easiest explained by an example, so here goes:
<target name="test">
<fileset id="fileset" dir="target">
<include name="*"/>
</fileset>
<echo>${toString:fileset}</echo>
<touch file="target/test"/>
<echo>${toString:fileset}</echo>
</target>
Outputs:
test:
[echo]
[touch] Creating target/test
[echo] test
What I ideally want is to have the fileset stay the same so I can have a before/after set (in order to get a changed set using <difference>, so if you know of a way to skip right to that...).
I've tried using <filelist> instead, but I can't get this correctly populated and compared in the <difference> task (they're also hard to debug since I can't seem to output their contents). I also tried using <modified/> to select files in the fileset, but it doesn't seem to work at all and always returns nothing.
Even if there is an alternative approach I would appreciate a better understanding of what ANT is doing in the example above and why.
The path selector is evaluated on the fly. When a file is added, it will reflect in the set when you use it.
You may able to evaluate and keep it in variable using pathconvert. Then this can be converted back to filest using pathtofilest
A fileset is something like a selector. It's a set of "instructions" (inclusions, exclusions, patterns) allowing to get a set of files.
Each time you actually do something with the fileset (like printing the files it "references"), the actual set of files is computed based on the "instructions" contained in the fileset.
As Jayan pointed out it might be worth posting the final outcome as an answer, so here's a simplified version with the key parts:
<fileset id="files" dir="${target.dir}"/>
<pathconvert property="before.files" pathsep=",">
<fileset refid="files"/>
</pathconvert>
<!-- Other Ant code changes the file-system. -->
<pathconvert property="after.files" pathsep=",">
<fileset refid="files"/>
</pathconvert>
<filelist id="before.files" files="${before.files}"/>
<filelist id="after.files" files="${after.files}"/>
<difference id="changed.files">
<filelist refid="before.files"/>
<filelist refid="after.files"/>
</difference>
So, here's the situation: I have a parent buildfile that defines a compilation task, and I want child buildfiles to optionally be able to add more JARs (which could be wherever) on to the classpath used by that compilation task.
Not all child buildfiles will have these additional dependencies, so I don't want to force them to define the additional dependency fileset. They should just be able to include the parent, and the compile task should just work.
(Obviously there are other required properties that configure the source directory and so on, but they don't enter into this. Also, the actual include/inheritance problem is a good bit more complicated, but hopefully whatever the right thing is for the simple case will work in the complex case too.)
I have something that works: The compile task in the parent buildfile refers to the additional dependency fileset regardless:
<target name="compile" depends="init-additional-dependencies">
<fileset id="global.dependency.fileset" dir="${global.library.directory}">
<include name="**/*.jar"/>
</fileset>
<javac ...>
<classpath>
<!-- should be the same for all buildfiles -->
<fileset refid="global.dependency.fileset"/>
<!-- should be populated by child buildfiles -->
<fileset refid="additional.dependency.fileset"/>
</classpath>
</javac>
</target>
...and the parent buildfile also has a task that creates this fileset, empty, so that javac doesn't blow up. However, the way I'm creating the empty fileset is dopey:
<target name="init-additional-dependencies">
<!-- override me! -->
<fileset id="additional.dependency.fileset" dir=".">
<include name="placeholder.does.not.exist.so.fileset.is.empty"/>
</fileset>
</target>
This works, but seems dumb, and it's hard to believe there isn't a better approach. What is that better approach?
I don't think there's been much discussion about this, so no 'convention' as such exists. The way that fileset works though, exclusions 'trump' inclusions, thus
<fileset refid="additional.dependency.fileset" dir="." excludes="**" />
should always be empty. That seems slightly preferable to both your placeholder file name technique, and the placeholder directory name and erroronmissingdir method.
The problem arises because, by default, there is an implicit include of all files beneath the parent directory of a fileset. Another option - perhaps not of direct use in your case - is to use a filelist instead. Because filelists are constructed from explicitly named files, if you don't name any, they are empty.
<filelist id="additional.dependency.filelist" />
By generalising, you can mix filesets and filelists, if you modify your classpath to use resources:
<filelist id="additional.dependency.resources" />
...
<classpath>
<!-- should be the same for all buildfiles -->
<fileset refid="global.dependency.fileset"/>
<!-- should be populated by child buildfiles -->
<resources refid="additional.dependency.resources"/>
</classpath>
the reference additional.dependency.resources can be either a fileset or a filelist (including the empty filelist), or any other file-based resource collection.
In the parent build file add:
<fileset id="additional.dependency.fileset" erroronmissingdir="false" dir="noop" />
For children that require additional artifacts to be added, define the fileset in the child build file:
<fileset id="additional.dependency.fileset" dir="..." includes="..." />
I have a number of macrodef tasks that I would like to call but would like to wrap the calls with some timestamping code. This could be easily done if the tasks were targets instead of macrodefs by using antcall.
Is it possible to do the same thing with macrodef?
Example:
The "macrocall" line is the hypothetical kind of task that I would like to use (akin to "antcall")
<target name="run.tests">
<run.named.test name="macro1" />
<run.named.test name="macro2" />
</target>
<macrodef name="run.named.test">
<attribute name="name" />
<sequential>
<echoTime />
<macrocall name="#{name}" />
<echoTime />
</sequential>
</macrodef>
<macrodef name="macro1">
</macrodef>
<macrodef name="macro2">
</macrodef>
Why not wrap your macro1 macro2 with targets and use an antcall for the "macrocall". the new macro1, macro2 targets will each run in their own project (properties and ref passed in, but not back out) which may or may not be a good thing depending on what you're trying to accomplish.
There no pure ant way to accomplish what you want as far as i know -- dynamically calling a task. You'd probably need to find some outside package to even come close, but it would probably be uglier.
This is a very late reply, but I had been struggling with the exact same issue for a while and just now came up with a solution, so I figured I'd contribute.
First of all, I think it's safe to definitively say that there is no way to do this simply with Ant alone, outside of doing something extremely hacky like echoing Ant code to a new file and then calling a macrodef from the file.
Anyway, I decided to use the Groovy Ant task to run some Groovy code. Here's what I came up with:
<groovy>
ant."${properties["macrodef.name"]}"("dir":properties["dir"])
</groovy>
Explanation:
-ant. is simply the prefix for telling Groovy to run an Ant task. For example, ant.echo() runs the <echo> task.
-"${properties["macrodef.name"]}" pulls the property named "macrodef.name" from my Ant project.
-With the two above combined together like this, I'm telling Groovy to run an Ant task with the same name as the value of the property "macrodef.name". For example, if ${macrodef.name} in my Ant project currently holds the value of "compile", Groovy will read this line as ant.compile.
-("dir":properties["dir"]) tells Groovy to run the macrodef with the attribute "dir" using the value of the Ant property also named "dir". To be clear, this is because my macrodef requires this attribute. In Ant, it would look like this: <compile dir="${dir}" />
I hope this helps anyone who comes across it! For the record, I wanted to avoid using the more generic <script> task, because apparently it runs noticeably slower than basic Ant or the Groovy task. The ideal solution would probably be to actually write a custom Ant task, but unfortunately I don't quite have to knowledge to do that yet.
There are two ways to resolve macrodef name dynamically
1) Macrodef names are not constant and resolved during load time depending on "what-to-say" variable. As a result, only one macrodef gets "say-something" name, there other one's name is not resolved (so not available to call)
<property name="what-to-say" value="bye"/>
<property name="say-${what-to-say}" value="say-something"/>
<macrodef name="${say-hi}">
<sequential>
<echo>hi!</echo>
</sequential>
</macrodef>
<macrodef name="${say-bye}">
<sequential>
<echo>bye!</echo>
</sequential>
</macrodef>
<target name="test">
<say-something/>
</target>
2) Create two additional files with macrodef definitions, e.g.
<project name="macrodefs-hi.xml>
<macrodef name="say-something">
<sequential>
<echo>hi!</echo>
</sequential>
</macrodef>
</project>
<project name="macrodefs-bye.xml>
<macrodef name="say-something">
<sequential>
<echo>bye!</echo>
</sequential>
</macrodef>
</project>
And include just one of them to your main project
<property name="what-to-say" value="bye"/>
<import file="macrodefs-${what-to-say}.xml"/>
<target name="test">
<say-something/>
</target>