I am running ant version 1.6.5 on CentOS 5.5. I used ant propertyfile task (an optional ant task) to update some properties in a property file before loading the property file. The property file task seems to be removing all the existing comments from the file just leaving it with the property key-value pairs.
Here is my code snippet from the build.xml file:
<target name="version">
<propertyfile file="${root.dir}/build/cbo_version.properties" >
<entry key="major_number" value="${major_number}"/>
<entry key="minor_number" value="${minor_number}"/>
<entry key="maintenance_number" value="${maintenance_number}"/>
<entry key="build_number" value="${build_number}"/>
</propertyfile>
</target>
Here is a snippet from my property file:
#
# This file was designed to contain basic information about a build/release such
# as its version, code label, etc. for the purpose of traceability.
#
major_number=1
minor_number=0
maintenance_number=0
build_number=18
Once I build my application, all the lines in the property file prefixed with "#" are deleted. I have tried the same code on mac os x 10.8.4 and with ant 1.8.2 and the code runs perfectly fine. I would like to have the comments left completely untouched by the propertyfile task. Please help
[Edited] Ant docu says about PropertyFile task:
Since Ant 1.8.0 comments and layout of the original properties file are preserved.
http://ant.apache.org/manual/Tasks/propertyfile.html
Related
nI see in build files of different project in Linux frequently use of "out.absolute.dir" and I'm really curious about what does it exactly mean.So I write a short build file which I mentioned in following lines
<project name="Test_Ant_APK" default="print">
<property name="cal.out.dir" location="${out.absolute.dir}"/>
<target name="print">
<echo>p=${cal.out.dir}</echo>
</target>
</project>
And when I run this build file from command line I got this output
Buildfile: /home/jody/workspace/Test_Ant_APK/build.xml
print:
[echo] p=/home/jody/workspace/Test_Ant_APK/${out.absolute.dir}
BUILD SUCCESSFUL
Total time: 0 seconds
I little confused about output.I think we should have p=/home/jody/workspace/Test_Ant_APK as output. Why we have ${out.absolute.dir}
at the end of output? what does it mean? Does this build file have problem?
Nothing wrong with your buildscript.
You adress a propertyvalue with syntax ${...}, but as the
property out.absolute.dir is not set within the project scope of your ant file it's getting echoed as is => ${out.absolute.dir} which is normal for properties not set - in your case its added to the dir your ant script resides, because of the use of location attribute in property task.
See the difference when using property task with value attribute instead :
<project name="foo">
<property name="cal.out.dir" value="${out.absolute.dir}"/>
<target name="print">
<echo>${cal.out.dir}</echo>
</target>
</project>
output :
[echo] ${out.absolute.dir}
I believe the propertyname $[out.absolute.dir} might be taken in several scripts due to the fact that property task with attribute location means (taken from ant manual) :
Sets the property to the absolute filename of the given file. If the
value of this attribute is an absolute path, it is left unchanged
(with / and \ characters converted to the current platforms
conventions). Otherwise it is taken as a path relative to the
project's basedir and expanded.
see ant manual property task for details.
If you want the value of project name attribute to be echoed, you must use the builtin property ${ant.project.name}, f.e :
<project name="foo">
<echo>$${ant.project.name} => ${ant.project.name}</echo>
</project>
see all builtin properties with :
<project>
<echo>ant builtin properties:</echo>
<echoproperties prefix="ant"/>
<echo>java builtin properties:</echo>
<echoproperties prefix="java"/>
</project>
I need to switch to Ant, I managed to compile and install the Android apk file but I didn't manage to transmit the property or a specific target to the referenced library.
My code on the build.xml in the referenced library :
<echo message="Property value is '${foo.dist}'" />
<target name="AfficherVersionAnt">
<echo message="Version d'Ant utilisée : ${ant.version}"/>
</target>
The same code is functional when I put it in the starting package.
<property name="foo.dist" value="true"/>
(and for the target, if I launch with the target)
My ant configuration was generated with :
"C:\Program Files (x86)\Android\android-sdk\tools\android" update project -p "D:\project"
And I don't see where I could set a link
Can someone help me ? I would need global variables or something like this
In eclipse you can define your own variables for ant
Go to external tools configuration > your profile > environnement, and define new environnement variable.
My build begins by defining 2 properties files, importing another build XML, and then commencing with all my other targets & tasks:
build.main.xml:
<project name="${proj.name}" default="assemble" basedir=".">
<!-- BASIC CONFIGURATIONS -->
<!-- Define build properties. -->
<property file="build.main.properties"/>
<property file="build.app.properties"/>
<!-- Imports. -->
<import file="${alt.build.file}"/>
<!-- Rest of buildscript omitted for brevity... -->
</project>
build.app.properties:
proj.name=test-proj
alt.build.file=build.app.xml
It seems that build.main.xml cannot seem to see/find any properties defined inside build.app.properties; specifically:
It cannot resolve ${proj.name}, and when I add the build.main.xml file to the Eclipse Ant view, the name of the build shows up as ${proj.name}
It cannot find build.app.xml imported from build.main.xml
What's going on here? Do ant builds only get to import one properties file or something?!? Where could I start troubleshooting?
Edit: using Eclipse editor my buildscript does not have any red/highlighted syntax errors that might be causing the ant plugin to work incorrectly, etc.
Edit: I am noticing issues with properties defined inside the build.main.properties to. If I try to echo them they don't get noticed by Ant either...
The Ant project name cannot be itself a property for the reason Jochen mentioned in his comment.
Try running your script with the -v option to see more logging. I have used a technique very similar to your <import file="${alt.build.file}"/> to branch my script based on the db platform, so there should be no problem with it.
I wondered if your property files are in the same directory then your build script is.
I'm using Ant + Ivy, and my company has recently set up a Nexus server for our own private libraries. Ivy can get dependencies from the Nexus server by using a ibilio resolver and m2compatible=true, but I have to put my credentials in a ivysettings.xml file.
How are different developers supposed to store their credentials?
Is the ivysettings.xml file not supposed to be commited in vcs?
I really don't want to store my password in plain text.
Use a settings file with properties controlling the Nexus credentials:
<ivysettings>
<property name="repo.host" value="default.mycompany.com" override="false"/>
<property name="repo.realm" value="Sonatype Nexus Repository Manager" override="false"/>
<property name="repo.user" value="deployment" override="false"/>
<property name="repo.pass" value="deployment123" override="false"/>
<credentials host="${repo.host}" realm="${repo.realm}" username="${repo.user}" passwd="${repo.pass}"/>
..
..
</ivysettings>
When you run the build you can then specify the true username and password:
ant -Drepo.user=mark -Drepo.pass=s3Cret
Update/Enhancement
Storing passwords as properties on the file system requires encryption.
Jasypt has a command-line program that can generate encrypted strings:
$ encrypt.sh verbose=0 password=123 input=s3Cret
hXiMYkpsPY7j3aIh/2/vfQ==
This can be saved in the build's property file:
username=bill
password=ENC(hXiMYkpsPY7j3aIh/2/vfQ==)
The following ANT target will decrypt any encrypted ANT properties:
<target name="decrypt">
<taskdef name="groovy" classname="org.codehaus.groovy.ant.Groovy" classpathref="build.path"/>
<groovy>
import org.jasypt.properties.EncryptableProperties
import org.jasypt.encryption.pbe.StandardPBEStringEncryptor
StandardPBEStringEncryptor encryptor = new StandardPBEStringEncryptor()
encryptor.setPassword(properties["master.pass"])
Properties props = new EncryptableProperties((Properties)properties, encryptor);
props.propertyNames().each {
properties[it] = props.getProperty(it)
}
</groovy>
</target>
Of course to make this work, the password used for encrypting the properties needs to be specified as part of the build.
ant -Dmaster.pass=123
This means the solution is only good for hiding data at rest.
For my purposes the command-line credentials weren't an option because I'm running through Jenkins and they'd be clearly pasted on the build output, so here was my solution which strikes a balance by being reasonably secure.
Create a properties file in your home directory that contains the sensitive information (we'll call it "maven.repo.properties")
repo.username=admin
repo.password=password
Near the top of your build file, import the property file
<property file="${user.home}/maven.repo.properties"/>
In your publish target under build.xml, set your ivy settings file location (which does get checked in to code control) but embed your credential properties
<target name="publish">
<ivy:settings file="ivysettings.xml">
<credentials host="repohostname" realm="Artifactory Realm" username="${repo.username}" passwd="${repo.password}"/>
</ivy:settings>
<!-- ivy:makepom and ivy:publish targets go here -->
</target>
Create your ivysettings.xml just as you did before, but strip out the username and passwd attributes
You can then leverage your operating system's permissions to make sure that the maven.repo.properties file is properly hidden from everybody except you (or your automatic build implementation).
The ivysettings.xml sample in Mark O'Connor's answer should actually be as follows:
<ivysettings>
<property name="repo.host" value="default.mycompany.com" override="false"/>
<property name="repo.realm" value="Sonatype Nexus Repository Manager" override="false"/>
<property name="repo.user" value="deployment" override="false"/>
<property name="repo.pass" value="deployment123" override="false"/>
<credentials host="${repo.host}" realm="${repo.realm}" username="${repo.user}" passwd="${repo.pass}"/>
..
</ivysettings>
Means, the property names should not be surrounded by ${...} (it took me quite a while to find out why this failed - but now I know how to debug ivy access - use commons-httpclient-3.0, set everything to verbose etc.)
Additional to Mark O'Connor's answer you can hide the password from your daily work and from the prying eyes of your workmates by putting these properties either into the antrc startup file or into the environment variables used by ant. Please note that they are not very secure in either place.
I have this in my build.xml:
<target depends="build-jar" name="proguard">
<taskdef resource="proguard/ant/task.properties" classpath="tools/proguard4.6/lib/proguard.jar" />
<proguard configuration="ant/proguard.conf" />
</target>
It works fine.
Inside the configuration file (i.e "ant/proguard.conf") I'm trying to access properties defined in this build.xml file but I'm always getting this kind of error:
Value of system property 'jar.final_name' is undefined in '<jar.final_name>' in line 1 of file '.......\ant\proguard.conf'
The error is clear. Question is how I do what I'm trying to?
If I'd do it the "Embedded ProGuard configuration options" way I could use these properties like any other property in build.xml, but I'm trying to keep the files separate.
How do I do that then?
By default, Ant doesn't provide a way to set java system properties for its tasks. You can only specify -D options in the ANT_OPTS system variable when starting Ant itself.
I'll consider supporting the use of Ant properties in referenced ProGuard configurations (being the developer of ProGuard).
For the time being, an acceptable solution might be to specify input and output jars in Ant's XML-style:
<proguard configuration="ant/proguard.conf">
<injar name="${injar}" />
<outjar name="${outjar}" />
<libraryjar name="${java.home}/lib/rt.jar" />
</proguard>
This part of the configuration is more closely tied to the Ant script anyway.