Working with simple ant's property is tricky & doesn't allow to set needed value easily (properties are immutable). Using ant-conrib's var tasks allows properties to be set and unset.
Any genuinue or good reason behind making ant property designed to work in such a complex way?.
<property name="some.ant.prop" value=""/>
<if>
<isset property="some.ant.prop"/>
<then>
<echo message="immutable ant prop - not good, defined and just even set to null string : ${some.ant.prop}"/>
<property name="some.ant.prop" value="no-effect-value"/>
<echo message="no-effect on changing already defined prop : ${some.ant.prop}"/>
<var name="some.ant.prop" unset="true"/>
<property name="some.ant.prop" value="any-value-accepted"/>
<echo message="Overwritten prop value: ${some.ant.prop}"/>
</then>
</if>
Not for discussion or argument , but its good to know on more feasible alternatives. Thanks.
Ant ain't a programming language !
Properties once set are immutable in ant by design.The Pros and Cons have been discussed (much too) often and i won't go into details.
Several possibilities to get over those limitations :
In the past people used antcall for that purpose - with all its drawbacks, search for 'antcall vs. macrodef' to get the details. Ant 1.6 introduced macrodef and Ant 1.8 came with a new local task.
If macrodef and local are not sufficient you may use script task with builtin javascript engine (since JDK 1.6) or Groovy to access ant api.
There are also Ant addons like f.e. antcontrib or Flaka. If antcontrib var / unset feels too clumsy for you, the
Flaka's let task provides a more straight approach for overwriting properties :
<!-- set a new property -->
<fl:let>foo := 'bar'</fl:let>
<!-- overwrite an existing property or userproperty
(those properties defined on the commandline via -Dfoo=bar ..)
notice the double '::' in foo ::= 'baz' -->
<fl:let>foo ::= 'baz'</fl:let>
Finally : Either get used to ant and its limitations (but don't use antcall !) oruse Ant addon use ant from groovy or switch to Gradle.
Related
I am trying to change the ant.project.name property after the project declaration. I know this is not advisable but it's the only way I can fix a big problem with my project.
I found some interesting posts like this one:
Ant - How to set ${ant.project.name} to project folder name?
Instead of using:
<project basedir="." default="package">
<basename property="ant.project.name"
file="${basedir}"/>
</project>
I'd like to directly set the ant.project.name using a "value" instead of a property "file".
Do you have any ideas or suggestions? Or alternative ways?
Thank you!
As others already mentioned, it's not recommended to change values of standard ant properties.
Also properties once set are immutable in ant by design and for good reasons. Overriding properties should be used wisely and rarely.
The property ant.project.name is usually set via name attribute of project =>
<project name="whatever"> but it's not mandatory, means <project> ... </project> is sufficient to make your xml a valid antscript.
In your case <echo>${ant.project.name}</echo> would echo ${ant.project.name}, as property is not set, so you may create it with property task in your script : <property name="ant.project.name" value="whatever"/>. But using a propertyname that is normally used for 'ant internals' seems not the best choice.
If property is set within project tag it's possible to overwrite the value via script task, using builtin javascript engine and ant api, f.e. :
<project name="foo">
<property name="bla" value="foobar"/>
<echo>1. $${ant.project.name} => ${ant.project.name}</echo>
<script language="javascript">
project.setUserProperty('ant.project.name', project.getProperty('bla'));
</script>
<echo>2. $${ant.project.name} => ${ant.project.name}</echo>
</project>
output :
[echo] 1. ${ant.project.name} => foo
[echo] 2. ${ant.project.name} => foobar
Notice : as ant.project.name is not a 'normal' property (those properties declared via property task within ant script), you have to use the method project.setUserProperty(String, String) instead of project.setProperty(String, String). Userproperties are properties defined via -Dkey=value commandline argument and enjoy a special protection.
Ant also provides a bunch of builtin properties
How to pass nested arguments from one ant target to another?
I need to pass a variable number of nested elements from one target to another.
I have a common file with all of my standard build tasks that's included in all of my projects.
I am adding a new custom task that takes a variable number of nested arguments
As a standard, all ant calls are made through the common file to ensure consistency of build style and logging.
Thus the new custom task and its nested child will be defined in the common script.
The project build script looks like this
<target name="projectBuild">
...
<ant target="_newFooTaskWrapper" antfile="commonFile">
<property name="_arg1" value="hello"/>
<property name="_arg2" value="world"/>
<nestedArg value="qux"/>
<nestedArg value="baaz"/>
...
<nestedArg value="AAAAA"/>
</ant>
...
</target>
The common script looks like this:
<target name ="_newFooTaskWrapper">
<echo message="Target _newFooTaskWrapper in project ${ant.project.name} from base directory ${basedir}"/>
<echo message="arg1 = ${_arg1}"/>
<echo message="arg2 = ${_arg2}"/>
<taskdef name="newFooTask" classname="org.foo.NewFooTask"/>
<typedef name="nestedArg" classname="org.foo.NewFooTask$NestedArg"/>
<newFooTask arg1="${_arg1}" arg2="${_arg2}">
<nestedArg value="qux"/>
<nestedArg value="baaz"/>
...
<nestedArg value="AAAAA"/>
</newFooTask>
Obviously, this isn't right. My question is, what's the right way to do this?
I need to pass a variable number of nested elements from one target to another.
For "varible", I assume you mean you don't know the exact number of the nested elements you want to pass to the task, so what you want is something like method(Object param...) in java, is it?
It's not a good idea to try such a way. Ant is not a scripting language but a build tool. It provides limited "scripting" possibilities.
However, you can try it in the following two ways:
1, If your nested element is just in the form of <elementName value="xx" />, you don't need anything complicated. Just pass another property containing a comma seperated list of the values, and process the list in your custom ant task. It's easy for Java to split the property into a list and process it.
2, If your nested element may be more complicated... maybe you can try reference:
Make a type fooTaskParams which can be referenced via an id:
<fooTaskParams id="_foo_task_params">
<nestedArg value="qux"/>
<nestedArg value="baaz"/>
...
<nestedArg value="AAAAA"/>
</fooTaskParams>
and pass the reference to the other build file:
<ant target="_newFooTaskWrapper" antfile="commonFile">
<property name="_arg1" value="hello"/>
<property name="_arg2" value="world"/>
<reference refid="_foo_task_params"/>
</ant>
and then make your task to be able to process the reference:
<newFooTask arg1="${_arg1}" arg2="${_arg2}" paramRefId="_foo_task_params" />
You may need to take care of reference override, or make your task able to process the ref as well as taking nested elements.
Read ant's manual about <ant> and <typedef> for more about this approach, and refer to SO Q&As like this when you encount any problem.
I want to use an condition property to set the property value to X if another property is defined and Y otherwise. However, I don't want the user to be able to override the condition property from the command line.
How can this be achieved?
Starting from ant 1.8 for some use cases local task may be applicable. Since a property is made local it starts with an empty value. It's scope is limited to current target, but you may pass it to subsequent targets using param argument in antcall.
Nope, you can't override a property set on the command line. At least, it's not easy to do. The whole purpose of overriding properties on the command line is to allow users to override defaults in order to make modification in the way your project builds. For example:
<property file="${basedir}/build.properties"/>
<property name="javac.debug" value="no"/>
<target name="compile">
<javac destdir="${main.destdir}"
debug="${javac.debug}">
By default, the Java code is compiled without debugging information. Maybe this is done to make jar files smaller, or faster interpretation, or maybe to make the code harder to decompile and read. Whatever reason, this build won't put debug information into the classfiles.
However, developers do want this debugging information, so they want to be able to override this setting:
$ ant -Djavac.debug=true compile
Or, they can create a build.properties file and put the value in there.
This type of issue comes up when you're not using Ant for builds. I know several sites that use Ant scripts to do deployments. I usually discourage this because Ant isn't really made for this type of thing. For example, Ant doesn't have any built in logic or loops. Once a property is set, it can't be changed. These are good ideas for a build language, but a terrible idea for a general purpose programming language.
Also, developers shouldn't be doing builds for QA or production. Those should be done by a build server that won't override defaults.
Now how to destroy this whole well thought out system and cause absolute havoc:
You can use the ant-contrib tasks in your project. Doing this will allow you to access the Ant Contrib var task to unset properties.
Download the ant-contrib.jar file (whatever the latest version is), and put it in a lib directory under your project. Then you can do this:
<project name="danger-will-robinson" default="package" basedir="."
xmlns:ac="http://ant-contrib.sourceforge.net">
<!-- Define the Ant-Contrib tasks -->
<taskdef=resource="net/sf/antcontrib/antlib.xml"
uri="http://ant-contrib.sourceforge.net">
<classpath>
<fileset dir="${basedir}/lib">
<include name="ant-contrib*.jar"/>
</fileset>
</classpath>
</taskdef>
<!-- Unset Property "foo", so you can use it -->
<ac:var name="foo" unset="true"/>
Note that the <classpath> points to the ant-contrib jar in the ${basedir}/lib directory. If you check that into your source repository, it will allow everyone who checks out your project to be able to do the build without installing the ant-contrib jar on their system.
Note that I've defined a "ac" XML namespace, so Ant-Contrib tasks won't overlap other possible third party tasks.
Properties in ant once set are immutable by design. You may overwrite an existing property with any scripting language that provides access to ant api, i.e. javascript.
JDK >= 1.6 already ships with a javascript engine, so you may use something like :
<project>
<property name="x" value="whatever"/>
<script language="javascript">
project.getProperty('x') ?
project.setProperty('foo', 'true') :
project.setProperty('foo', 'false');
</script>
<echo>$$[foo} => ${foo}</echo>
</project>
out of the box.But that won't help if someone uses ant -f yourbuild.xml -Dfoo=bla !! as userproperties (those properties defined via -Dkey=value) have a special protection.
So your requirement "..However, I don't want the user to be able to override the condition property from the command line". is not fullfilled.
But the let task from Ant addon Flaka provides the possibillity to overwrite even userproperties :
<project xmlns:fl="antlib:it.haefelinger.flaka">
<property name="x" value="whatever"/>
<!--
:= defines a new property whereas
::= overwrites any existing property
even userproperties
-->
<fl:let> foo ::= has.property['x'] ? 'true' : 'false'</fl:let>
<echo>$$[foo} => ${foo}</echo>
</project>
Run both scripts with ant -f yourbuild.xml -Dfoo=bla to see the difference.
Ant api has also method project.setUserProperty(String,String) so you may use also:
...
<script language="javascript">
project.getProperty('x') ?
project.setProperty('foo', 'true') :
project.setProperty('foo', 'false');
project.getUserProperty('x') ?
project.setUserProperty('foo', 'true') :
project.setUserProperty('foo', 'false');
</script>
...
to prevent the foo property to be set via .. -D .. and it will work even if property x is defined on commandline -Dx=whatever You have to make your choice, script task with javascript out of the box or Flaka let task
oneline solution but Flaka jar needed.
I'm writing a velocity macro within which I have some ant tasks. Within a #foreach loop in the velocity macro, I have a pathconvert task:
#foreach(<iterate through something>)
<pathconvert property='filename' refid='swf.file'>
<mapper>
<chainedmapper>
<flattenmapper/>
<globmapper from='*-d.swf' to='*'/>
</chainedmapper>
</mapper>
</pathconvert>
#end
The problem I have is that the 'filename' property gets set only once, during the first iteration, since properties in ANT are immutable.
But I need the filename to be set during each iteration. Is there a way to get this done?
If there was a way to reset the property, I could do that at the end of each iteration. Or is there a better way to do this?
Any help would be highly appreciated!
Thanks in advance,
Anand
You could use ant-contrib's variables. They act like mutable properties.
http://ant-contrib.sourceforge.net/tasks/tasks/variable_task.html
Use the new lexically scoped properties in Ant 1.8:
"Lexically scoped local properties, i.e. properties that are only defined inside a target, sequential block or similar environment."
Annoucement.
Properties in Ant were designed to be immuatable, but they gave in to popular demand and gave us variables. Your alternative is to write a custom task ( in Java or a Dynamic Language) but this seems like a good compromise.
The following snippet illustrates an ant property which I guess is not documented. Properties are immutable, but references are mutable. So any data type which has no name, but a reference, is mutable. For example a fileset. But today I found a way to have a kind of mutable property. Connected with local task or some other tricks it may be a way of having variables in ant.
<property name="a" value="aaa" id="refa" />
<property name="b" refid="refa" />
<echo>${b}</echo>
<property name="c" value="ccc" id="refa" />
<property name="d" refid="refa" />
<echo>${d}</echo>
The output is:
aaa
ccc
Although in both cases a reference refa is printed.
Here is a post about it. And another one.
Use a combination of for + let task from Ant Plugin Flaka to overwrite existing properties.
See some snippets here.
I'm currently working with some developers who like to set up Ant tasks that define environment specific variables rather than using properties files. It seems they prefer to do this because it's easier to type:
ant <environment task> dist
Than it is to type:
ant -propertyfile <environment property file> dist
So for example:
<project name="whatever" default="dist">
<target name="local">
<property name="webXml" value="WebContent/WEB-INF/web-local.xml"/>
</target>
<target name="remote">
<property name="webXml" value="WebContent/WEB-INF/web-remote.xml"/>
</target>
<target name="build">
<!-- build tasks here --->
</target>
<target name="dist" depends="build">
<war destfile="/dist/foo.war" webxml="${webXml}">
<!-- rest of war tasks here -->
</war>
</target>
I am finding it hard to convince them that properties files are they right way to go. I believe properties files are better because:
They provides more flexibility - if you need a new environment just add a new properties file
It's clearer what's going on - You have to know about this little "trick" to realize what they're accomplishing
Doesn't provide default values and the ability to use overrides - if they used property files they could provide defaults at the top of the project but have the ability to override them with a file
Script won't break if an environment task isn't supplied on command line
Of course all they hear is that they need to change their Ant script and have to type more on the command line.
Can you provide any additional arguments in favor of properties files over "property tasks"?
Properties tasks tightly couple the build file to environments. If your fellow developers are arguing that they "have to change their ant script" with your suggestions, why aren't they arguing about changing it every time they have to deploy to a new environment? :)
Perhaps you can convince them to allow both properties file and command-line configuration. I set up my Ant builds so that if a build.properties exists in the same directory as the build.xml, it reads it in. Otherwise it uses a set of default properties hard-coded into the build. This is very flexible.
<project name="example">
<property file="build.properties"/>
<property name="foo.property" value="foo"/>
<property name="bar.property" value="bar"/>
...
</project>
I don't provide a build.properties with the project (i.e. build.properties is not versioned in SCM). This way developers aren't forced to use the property file. I do provide a build.properties.example file that developers can reference.
Since Ant properties, once set, are immutable, the build file will use properties defined in this order:
Properties provided with -D or -propertyfile via the command line
Properties loaded from build.properties
Default properties within build.xml
Advantages of this approach:
The build file is smaller and therefore more maintainable, less bug-prone
Developers that just can't get away from setting properties at the command line can still use them.
Properties files can be used, but aren't required
The arguments you have are already pretty compelling. If those arguments haven't worked, then arguing isn't going to solve the problem. In fact, nothing is going to solve the problem. Don't assume that people are rational and will do the most practical thing. Their egos are involved.
Stop arguing. Even if you win, the resentment and irritation you create will not be worth it. Winning an argument can be worse than losing.
Make your case, then let it go. It's possible that after a while they will decide to switch to your way (because it actually is better). If that happens, they will act like it was their own idea. There will be no mention of your having proposed it.
On the other hand, they may never switch.
The only solution is to work towards a position of authority, where you can say how things are to be done.
The problem with the first solution (using ant property) is basically hardcoding.
It can be convenient when you start a project for yourself but quickly you have to remove that bad habit.
I'm using a property file close to what said robhruska except that I have committed the build.properties file directly. This way you have a default one.
In other hand, I understand I could add those default values in the build.xml. (I will probably try that in the next hours/days ;-) ).
Anyway, I really don't like the first approach and I would force those guys to follow the second one ...