I am banging my head on the walls with ant...
My target is the following:
<target name="js.minify">
<apply executable="java">
<arg line="-jar"></arg>
<arg path="path_to_file/yuicompressor-2.4.7.jar"></arg>
<arg line="-v"></arg>
<srcfile></srcfile>
<arg line="-o"></arg>
<targetfile></targetfile>
<globmapper from="*.js" to="*.min.js" casesensitive="no"/>
<fileset id="jsFiles" dir="${artifactsdir}/js">
</fileset>
</apply>
</target>
Here's the funny thing, with the mapper in the code nothing gets processed. I can even change the name of the executable to some non existing application and it won't complain, ie it skips the apply. If I remove the mapper and the target file, at least I get some error message. If I try another process with just the source file, it runs. I really narrowed it down to mapper which seems to select the files only if they have changed (?!), ie if I edit them and save them, it works... any idea how to force mapper to take any files, even non modified (whatever that means) files?
It sounds like you want to ignore the timestamp checking you get when you use <targetfile>.
You can do that using the force="true" parameter of the <apply> task. (It's at the bottom of the list of parameters, note that this option was new at Ant version 1.6.3.)
<apply executable="java" force="true">
...
Related
I have code for creating zip file in ant build script.
<target name="zip-dist" description="archiving artifacts">
<zip destfile="${artifacts}/${zipfile}.zip" update="false" basedir="${target.dist}" includes="*.xyz-*" />
</target>
When file is being extracted using win zip right click -> Extract All... there's no warning, but while extracting with 7-zip showing 'Warnings: Headers Error' but its successful.
I know this has no effect on the output as its just a warning so suggested users to ignore it or use win-zip method.
But trust me it is impossible to make them understand and they all are keep on eating my head.
There are many users and I am banging my head repeating same thing again and again. Still they want it to be fixed.
Can I use any attribute in ant-zip target or should I use any different zipping technique in ant build?
I have searched multiple online sources, this is last hope!
Please help.
I had the same issue.
Fixed adding only one attribute, to force Zip64 extensions:
zip64Mode="always"
Try and should work for you too.
Instead of regular zip target used 7-zip to create zip.
<property name="7z.exe" value="C:/Program Files/7-Zip/7z.exe" />
<target name="zip-dist" description="archiving artifacts">
<exec executable="${7z.exe}">
<arg value="a" />
<arg value="-tzip" />
<arg value="${artifacts}/${zipfile}.zip" />
<arg value="${target.dist}/*.xyz-*" />
</exec>
</target>
As 7-zip includes all necessary information regarding header, so that warning will not occur.
Of course, 7-zip must be available in system.
I've got a situation where we're generating an Ant <path> which may contain some directories which don't actually exist. Unfortunately this is being fed into bnd, which blows up if anything in the path is missing.
So what I want is a way to filter a <path> to keep only those path elements which actually exist.
Is there a simple way to say this in Ant, or do I have to write a task?
I believe I have found an answer:
<path id="bnd.cp.existing">
<restrict>
<path refid="bnd.cp"/>
<exists/>
</restrict>
</path>
<!-- To see when it happens, add the following: -->
<echo message="bnd classpath is: ${toString:bnd.cp.existing}"/>
<iff>
<not>
<equals arg1="${toString:bnd.cp.existing}"
arg2="${toString:bnd.cp}"/>
</not>
<then>
<echo message=" trimmed from: ${toString:bnd.cp}"/>
</then>
</iff>
The restrict operation can take a path-like structure as input and return a version of it with the requested filtering applied -- in this case keep only the path elements which actually exist. This is then re-bound to a new ID for use by the <bnd> operation.
Dear, I currently face some problem to retrieve the value of a property setted in a foreach loop. Maybe one of you could help me...
The purpose is to check if one file of a folder has been modified since the corresponding jar has been generated. This way I know if I have to generate the jar again.
What I do is to go through the folder with a foreach loop and if one file match my test, set a property to true.
The problem is that my variable doesn't seems to exist after my loop... Here is a simplified code example that has the same problem:
<target name="target">
<taskdef resource="net/sf/antcontrib/antlib.xml" classpath="${lib.dir}/ant-contrib.jar"></taskdef>
<foreach target="setVar" param="var" list="a,b"/>
<echo>myreturn in target: ${env.myreturn}</echo>
<property name="env.myreturn" value="c"/>
<echo>myreturn in second: ${env.myreturn}</echo>
</target>
<target name="setVar">
<property name="env.myreturn" value="${var}"/>
<echo>myreturn in setVar: ${env.myreturn}</echo>
</target>
The result of this code is:
target:
setVar:
[echo] myreturn in setVar: a
setVar:
[echo] myreturn in setVar: b
[echo] myreturn in target: ${env.myreturn}
[echo] myreturn in second: c
BUILD SUCCESSFUL
It seems that the variable is correctly set as it could be printed in the "setVar" target but no way to retrieve value from the calling target.
I also know it's not possible to assign a value to a property twice. But the problem doesn't even occurs... When it'll be the case I could add a check on the value of the property before to assign it to be sure it is not already initialized...
Do you have a clue on the way I can solve my problem ???
Many thanks in advance for your help :)
Try <for> task from ant-contrib instead of <foreach>. The <for> task takes advantage of Ant macro facility that came later. It works faster and is more flexible than the older <foreach> task. You are in the same project context when using <for>. That means properties set in the loop will be visible outside of the loop. Of course, normal rules for properties apply... you only get to set it once... unless you use <var> task from ant-contrib to overwrite or unset previously set properties.
Ah the joys of Ant hacking.
Not sure about your foreach problem, but can you not use the uptodate task for your requirement?
Even if I don't need it anymore thanks to sudocode, I found a solution for my question. Maybe it could be useful for someone else...
A collegue talked about the "antcallback" target of ant-contrib: it allows to return a result from a called target to the calling one. With a combination of "for" target and "antcallback" it is possible to do what I wanted to do:
<target name="target">
<taskdef resource="net/sf/antcontrib/antlib.xml" classpath="${lib.dir}/ant-contrib.jar"></taskdef>
<for param="file">
<path>
<fileset dir="../myDirectory" includes="**/*" />
</path>
<sequential>
<antcallback target="setVar" return="retValue">
<param name="file" value="#{file}"/>
</antcallback>
</sequential>
</for>
<echo>result: ${retValue}</echo>
</target>
<target name="setVar">
<property name="retValue" value="${file}"/>
</target>
"file" contains the name of the file in the directory. It is given to the called target as parameter with value "#{file}" ('#' necessary due to "for" target implementation).
At the end of the main target, ${retValue} contains the first value setted by the "setVar" target. No error is thrown when trying to set it multiple times, so it's not necessary to check if variable has already been instantiated before to set it in "setVar" target.
The <foreach> task uses the same logic as <antcall> under the covers, and any proprrties set inside a target invoked by <antcall> do not have scope beyond the execution of that target.
In other words, the env.myreturn property that you define in the setVar target is lost as soon as execution of that target completes.
This sort of scripting really isn't what Ant is designed for. The Ant-contrib library tries to patch up the holes, but it's still bending it way out of shape.
If you need to write such scripts, and want to use Ant tasks to achieve them, have a look at Gradle instead. It's a rather lovely blend of Groovy (for scripting) and Ant (for the tasks).
The other approaches here (<for>, <var>, <groovy>properties.put(....)</groovy>, <property>, <antcallback>) did not work with ANT 1.9.4, so I used the file system similar to this (pseudocode):
<target name="outer">
<for> <antcall target="inner" /> </for>
<loadproperties srcfile="tmpfile.properties" />
<echo message="${outerprop}" />
</target>
<target name="inner">
<!-- did not work: -->
<!--
<property name="outerprop" value="true" />
<var name="outerprop" value="true" />
<groovy>properties.put('outerprop','true')</groovy>
<antcallback target="setouterprop" />
-->
<echo message="outerprop=true" file="tmpfile.properties" />
</target>
Maybe the other approaches did not work because of my <antcall>, but I need it here. (outerprop is initially unset)
It sounds a little far fetched to me, but is there an ANT task for watching a directory for changes and then running a particular ANT class when the directory changes?
If files can only be added to or changed in the watched directory, then you can use this simple OutOfDate task from antcontrib.
<property name="watched-dir.flagfile"
location="MUST be not in watched dir"/>
<outofdate>
<sourcefiles>
<fileset dir="watched-dir"/>
</sourcefiles>
<targetfiles>
<pathelement location="${watched-dir.flagfile}"/>
</targetfiles>
<sequential>
<!--Tasks when something changes go here-->
<touch file="${watched-dir.flagfile}"/>
</sequential>
</outofdate>
If files can disappear from the watched-dir, then you have more complicated problem, that you can solve by creating shadow directory structure of the watched dir and checking if its consistent with the watched-dir. This task is more complex, but I'll give you a script to create a shadow directory, as it is not straight forward:
<property name="TALK" value="true"/>
<property name="shadow-dir"
location="MUST be not in watched dir"/>
<touch
mkdirs="true"
verbose="${TALK}"
>
<fileset dir="watched-dir">
<patterns/>
<type type="file"/>
</fileset>
<!-- That's the tricky globmapper to make touch task work -->
<globmapper from="*" to="${shadow-dir}/*"/>
</touch>
<!--
Due to how touch task with mapped fileset is implemented, it
truncates file access times down to a milliseconds, so if you
would have used outofdate task on shadow dir it would always
show that something is out of date.
Because of that, touching all files in ${shadow-dir} again fixes
that chicken and egg problem.
-->
<touch verbose="${TALK}">
<fileset dir="${shadow-dir}"/>
</touch>
With shadow directory created, I'll leave the task of checking directory consistency as an exercise for the reader.
Yes there is an Ant Task that will do this:
https://github.com/chubbard/WatchTask
It requires 1.7+. It can watch any number of filesets, and invoke any target depending on which fileset it came from.
You might be able to use the Waitfor task to achieve what you want. It blocks until one or more conditions (such as the presence of a particular file) become true.
You can combine the apply task with a fileset selector
<apply executable="somecommand" parallel="false">
<srcfile/>
<fileset dir="${watch.dir}">
<modified/>
</fileset>
</apply>
The fileset will check the files against a stored MD5 checksum for changes. You'll need to put ANT into a loop in order to repeatedly run this check. this is easy to do in Unix:
while true
> do
> ant
> sleep 300
> done
The Ant replace task does an in-place replacement without creating a new file.
The below snippet replaces tokens in any of the '*.xml' files with the corresponding values from the 'my.properties' file.
<replace dir="${projects.prj.dir}/config"
replacefilterfile="${projects.prj.dir}/my.properties"
includes="*.xml" summary="true" />
I want those files that had their tokens replaced to be created named after a pattern (e.g.) '*.xml.filtered', and keep the original files.
Is this possible in Ant with some smart combination of tasks?
There are a couple of ways to get close to what you want without copying to a temporary directory and copying back.
Filtersets
If the source files can be changed so that the parts to be replaced can be delimited with begin and end tokens, as in #date# (# is the default token, but it can be changed) then you can use the copy task with a globmapper and a filterset:
<copy todir="config">
<fileset dir="config" includes="*.xml" />
<globmapper from="*.xml" to="*.xml.filtered" />
<filterset filtersfile="replace.properties" />
</copy>
If replace.properties contains FOO = bar, then any occurrence of #FOO# in a source xml file file be replaced with bar in the target.
Note that the source and target directories are the same, the globmapper means the target files and named with the suffix .filtered. It's possible (and more usual) to copy files into a different target directory)
Filterchains
If the source file can't be changed to add begin and end tokens, a possible alternative would be to use a filterchain with one or more replacestring filters instead of the filterset:
<copy todir="config">
<fileset dir="config" includes="*.xml" />
<globmapper from="*.xml" to="*.xml.filtered" />
<filterchain>
<tokenfilter>
<replacestring from="foo" to="bar" />
<!-- extra replacestring elements here as required -->
</tokenfilter>
</filterchain>
</copy>
This will replace any occurrence of foo with bar, anywhere in the file, which is more like the behaviour of the replace task. Unfortunately this way means you need to include all your replacements in the build file itself, you can't have them in a separate properties file.
In both cases the copy task will only copy source files that are newer than the target files, so unnecessary work won't be done.
Copy then replace
A third possibility (that has just occured to me whilst writing up the other two) would be to perform the copy first to the renamed files, then run the replace task specifying the renamed files:
<copy todir="config">
<fileset dir="config" includes="*.xml" />
<globmapper from="*.xml" to="*.xml.filtered" />
</copy>
<replace dir="config" replacefilterfile="replace.properties" summary="true"
includes="*.xml.filtered" />
This might be the closest solution to the original requirement. The downside is that the replace task will be run each time on the renamed files. This could be a problem for some replacement patterns (admittedly they would be odd ones like foo=foofoo, but they would be okay with the first two methods) and you will be doing unnecessary work when the dependencies don't change.
The replace task doesn't observe dependencies, instead it carries out the replacement by writing a temporary file for each input file. If the temporary file is the same as the input file, it is discarded. A temporary file that differs from the input file is renamed to replace that input. This means all the files are processed, even if none of them need be - hence it can be inefficient.
The original solution to this question was to carry out a copy-replace-copy. The second copy isn't needed though, as a mapper can be used in the first. In the copy, dependencies can be used to restrict processing to just the files that have changed - by means of a depend selector in an explicit fileset:
<copy todir="${projects.prj.dir}">
<fileset dir="${projects.prj.dir}">
<include name="*.xml" />
<depend targetdir="${projects.prj.dir}">
<mapper type="glob" from="*.xml" to="*.xml.filtered" />
</depend>
</fileset>
<mapper type="glob" from="*.xml" to="*.xml.filtered" />
</copy>
That will restrict the copy fileset to just those files that have changed. An alternative syntax for the mappers is:
<globmapper from="*.xml" to="*.xml.filtered" />
The simplest replace would then be:
<replace dir="${projects.prj.dir}"
replacefilterfile="my.properties"
includes="*.xml.filtered" />
That will still process all the files though, even if none of them need undergo replacements. The replace task has an implicit fileset and can operate on an explicit fileset, but unlike similar tasks the implicit fileset is not optional, hence to take advantage of selectors in an explicit fileset you must make the implicit one 'do nothing' - hence the .dummy file here:
<replace dir="${projects.prj.dir}"
replacefilterfile="my.properties">
includes=".dummy" />
<fileset dir="${projects.prj.dir}" includes="*.xml.filtered">
<not>
<different targetdir="${projects.prj.dir}">
<globmapper from="*.xml.filtered" to="*.xml" />
</different>
</not>
</fileset>
</replace>
That will prevent the replace task from needlessly processing files that have previously undergone substitution. It doesn't, however, prevent processing of files that haven't changed and don't need substitution.
Beyond that, I'm not sure there is a way to 'code golf' this problem to reduce the number of steps to one.
There isn't a multiple string replacement filter that can be used in a copy task to achieve the same affect as replace, which is a shame because that feels like it would be the right solution.
One other approach would be to generate the xml for a series of replace string filters and then have Ant execute that. But that will be more complex than the existing solution, and prone to problems with replacement strings that, if pasted into an xml fragment will result in something that can't be parsed.
Yet another approach would be to write a custom task or script task to do the work. If there are many files and the copy-replace solution is judged to be too slow, then this might be the way to go. But again, that approach is less simple than the existing solution.
If the requirement is to minimise the work done in the processing, rather than to come up with the shortest Ant solution, then this approach might do.
Make a fileset containing a list of inputs that have changed.
From that fileset create a comma-separated list of corresponding filtered files.
Carry out the copy on the fileset.
Carry out the replace on the comma-separated list.
A wrinkle here is that the implicit fileset in the replace task will fall back to processing everything if no files have changed. To overcome this we insert a dummy file name.
<fileset id="changed" dir="${projects.prj.dir}" includes="*.xml">
<depend targetdir="${projects.prj.dir}">
<globmapper from="*.xml" to="*.xml.filtered" />
</depend>
</fileset>
<pathconvert property="replace.includes" refid="changed">
<map from=".xml" to=".xml.filtered" />
</pathconvert>
<copy todir="${projects.prj.dir}" preservelastmodified="true">
<fileset refid="changed" />
<globmapper from="*.xml" to="*.xml.filtered" />
</copy>
<replace dir="${projects.prj.dir}"
replacefilterfile="my.properties"
includes=".dummy,${replace.includes}" summary="true" />