I am running a build.xml which is referring to the property file named ant.properties and I have declared the same in my build.xml but when i run the build.xml on my Linux machine it gives below error
build.xml:15: Property application was circularly defined.
It is working fine with an existing windows VDI but now we are migrating to new Linux server and hence tried the same existing build and properties file
property file="ant.properties" is what I am using in my build.xml
I am not sure why it is saying circularly defined as I am sure nothing is running gin loop and my properties file does not have reference back to my build.xml to create a loop.
This happened to us due to us referencing a property which had not been added to our properties file. As a result ant was trying to pull the property from the same one that was being declared.
Bad declaration:
<entry key="my.prop.name" value="${my.prop.name}"/>
To fix it we just had to add a check to see if the property was set or not as it was an optional one.
<if>
<isset property="my.prop.name" />
<then>
<propertyfile file="path/to/config.properties">
<entry key="my.prop.name" value="${my.prop.name}"/>
</propertyfile>
</then>
</if>
This fixed our circular dependency issue and allowed the property to be optional in the project.
Related
I need to retrieve all the properties' names from a properties file before loading it (using Ant)
I'll go into detail to explain the whole process:
A first properties file (let's name it as a.properties) is read and
all its properties loaded as project's properties.
#a.properties's contents
myvar1=1
myvar2=someTextHere
A second file (let's say b.properties) has to be loaded on the
project. Some already-set properties can also be contained in this
second file, so what we have to do is to update such variables with
the value found on it (by means of the ant-contrib's var target)
#b.properties's contents
myvar1=2 #updated value for a property that's is already set on the project
myvar3=1,2,3,4,5,6
So the expected subset (from a ANT project's properties perspective)
of property/value pairs would be:
myvar1=2
myvar2=someTextHere
myvar3=1,2,3,4,5,6
We cannot change the order in which those files are loaded on the project, which would be the easiest way of solving the issue (because of the behavior adopted by Ant when setting's properties)
Any feedback will be highly appreciated.
Regards
I assume that you need to read properties from different files before you build your source code
<target name=-init-const-properties description="read all properties required">
<propertyfile file="AbsolutePathToPropertyFile" comment="Write meaningfull
about the properties">
<entry value="${myvar1}" key="VAR1"/>
<entry value="${myvar2}" key="VAR2"/>
</propertyfile>
</target>
Note: you need to add proper AbsolutePathToPropertyFileand comment if required
In the target -init-const-properties you can add as many files you want to read and use this target as dependent target in which you going to use these property values. hope this will answer your question
I recommend having a standard file for build defaults called "build.properties". If you need to override any settings, then create an optional file called "build-local.properties".
My advice is to keep build logic simple. Using the ant-contrib extension to make properties act like variables is rarely needed in my experience.
Example
├── build-local.properties
├── build.properties
└── build.xml
Running the project produces the following output, where the value "two" is substituted:
$ ant
build:
[echo] Testing one, dos, three
Delete the optional file and it goes back to default values:
$ rm build-local.properties
$ ant
build:
[echo] Testing one, two, three
build.xml
The secret is the order in which the property files are loaded. If they don't exist then they don't create properties.
<project name="demo" default="build">
<property file="build-local.properties"/>
<property file="build.properties"/>
<target name="build">
<echo message="hello ${myvar1}, ${myvar2}, ${myvar3}"/>
</target>
</project>
build.properties
myvar1=one
myvar2=two
myvar3=three
build-local.properties
myvar2=dos
Finally, the approach I followed was to specify the second properties file (b.properties) from the command line:
ant <my_target> -propertyfile b.properties
So that's work fine to me...
Thanks all of you for your help.
i have a requirement that as follows.
I have a .properties file (with name=value pair) from which i am reading couple of properties.
i want to check a particular property exist or not.
i am getting the error with if doesn't support the "name" attribute for the following code.
where JavaProjectName,projDir are the names getting from the .properties file.
<if name="${JavaProjectName}" exists="true">
<property name="importJavaProject" value="${projDir}/${JavaProjectName}"/>
</if>
can you please tell me where am i doing wrong.
Read the document of <if> task first. It doesn't support the way you wrote.
It should be:
<if>
<isset property="JavaProjectName" />
<then>
<property name="importJavaProject" value="${projDir}/${JavaProjectName}"/>
</then>
</if>
However, you want to set a property importJavaProject when another property JavaProjectName has been set before (in the build file or in a properties file imported). So, what if JavaProjectName has not been set?
You should either think of an <else> part, or fail the build.
If you just want to check for existence and fail the build when it does not exist, just use <fail>:
<fail unless="JavaProjectName"/>
Also check Condition task and "Supported conditions".
Addition:
Also read the question posted by ManMohan in the comment more carefully. For "check the property existence in .properties file", the accepted answer of that question checks both "whether the property has been set" and "whether its value is empty".
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.
All my projects and their versions are defined in a properties file like this:
ProjectNameA=0.0.1
ProjectNameB=1.4.2
I'd like to iterate over all the projects, and use their names and versions in an Ant script.
At present I read the entire file using the property task, then iterate over a given list in a for loop like this:
<for list="ProjectNameA,ProjectNameB" param="project">
<sequential>
<echo message="#{project} has version ${#{project}}" />
</sequential>
</for>
How can I avoid the hard-coding of the project names in the for loop?
Basically iterate over each line and extract the name and the version of a project as I go.
Seeing as you're already using antcontrib for, how about making use of the propertyselector task:
<property file="properties.txt" prefix="projects."/>
<propertyselector property="projects" match="projects\.(.*)" select="\1"/>
<property file="properties.txt" />
<for list="${projects}" param="project">
...
</for>
The idea here is to read the properties once with the projects prefix, and use the resulting set of properties to build a comma-separated list of projects with the propertyselector task. Then the properties are re-read without the prefix, so that your for loop can proceed as before.
Something you want to keep in mind, if you are reading additional .property files (besides build.properties) is scoping. If you read an additional file (via the property file="foo.property") tag, ant will show that the file was read, and the properties loaded. However, when you goto reference them, they come up un-defined.
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 ...