CODEWITHSUNDEEP
fileantpropertiestask
itomorow
itomorow

Reputation: 3

Reading properties in properties file with ant not respects order

Reading properties in properties file with ant not respects order.

The order is not respected:

Example:

<property file="build.properties" prefix="prefix."/>
<propertyselector property="cases" match="prefix.project\.(.*)" select="\1"/>
<for list="${cases}" param="pr">
<sequential>
<echo message="Project: @{pr} Version: ${prefix.project.@{pr}}"/>
</sequential>
</for>

with:

build.properties

project.1 = 1.2.3
project.8 = 5.9.4
project.4 = 3.5.0

Get:

 Project: 8 Version 5.9.4
 Project: 1 Version 1.2.3
 Project: 4 Version 3.5.0

(And the result seems to randomly change) I have to build them in the order like they appear in the build.properties file ??

Upvotes: 0

Views: 5250

Answers (3)

David W.
David W.

Reputation: 107040

The property file is being read in the correct order. You can test this by simply putting in duplicate properties and see which one gets defined. Here's build.properties:

dup.prop = foo
dup.prop = bar

And here's my Ant script:

<project>
    <property file="build.properties"/>
    <echo>Dup.prop is set to "${dup.prop}".</echo>
</project>

Running this, I'll get:

Dup.prop is set to "foo".

That's because the value foo is defined first in build.properies, and once a property is defined, it cannot be (easily) changed.

What you're trying to do is to access the properties in the order they're defined. That isn't guaranteed because properties are stored in a hash.

You mention sub-projects, and those sub-projects must be built in a particular order. Unfortunately, it's hard to tell exactly what could be the issue since you didn't give us an outline of your actual issue and some sample build scripts for projects and sub-projects.

First, Ant is a build matrix language which means it has a dependency hierarchy. The biggest issue developers have is attempting to force build matrix languages to execute in a particular order. You should specify a dependency hierarchy in your build.xml files (and the fewer there are, the easier it is for Ant to get things right).

If sub-project "B" depends upon a jar file in sub-project "A", It should be in sub-project "B"'s Ant script a dependency on sub-project "A" jar build.

<project name="proj-b"/>
    ...
    <target name="build-jar"
        depends="test.if.jar.exists"
        unless="jar.exist">
        <ant directory="${proj.a.dir}"
           target="build.depend.jar"/>
    </target>

    <target name="test.if.jar.exists">
        <condition property="jar.exists">
           <available file="${proj.a.dir}/dist/${dend.jar.file}"/>
        </condition>
    </target>

    <target name="compile"
        depends="build-jar">
        ....
    </target>
    ...
</project>

In the above build.xml for Project "B", I depend upon some jar file that Project "A" builds before I can compile Project "B". Therefore, my compile task depends upon build-jar which will build Target "A"'s jar file. To prevent this task from building Project "A"'s jar over and over, I use <condition> as a test to see if this jar exists. If it already does, I don't rebuild the jar.

In this case:

  • Target "compile" is called. That target realizes it depends upon Target "build-jar".
  • Before Target "compile" is executed. Target "build-jar" is first called.
  • Target "build-jar" depends upon Target "test.if.jar.exists".
  • Before "build-jar" is executed, it calls Target "test.if.jar.exists"
  • In Target "test.if.jar.exists", if the jar already exists, the property jar.exists will be set.
  • Now, Target "build-jar" is active, and looks to see if the property jar.exists is set. If it is, the target won't execute.
  • Finally, control returns to Target "compile" which then executes.

Here I'm not enforcing order directly. Instead, I merely have a dependency hierarchy that I specify, and I let Ant figure out exactly what to do.

If dependent jar issues are a big issue, you can also look into Ivy. Ivy allows you to create a Jar Repository. Your projects that build jars the rest of your projects are dependent upon can fetch the needed jars from this repository. This is very similar to Maven. In fact, Ant with Ivy can use Maven repositories. We use Artifactory, a local Maven repository manager, for our Ant projects.

You can also try the <subant> task which does allow you to specify a buildpath which would allow you to say build sub-project "A" before sub-project "B". You can define the buildpath in another Ant XML file which could be dependent upon customer and then use <import> to import the build path for that project.

Upvotes: 2

Kartikeya
Kartikeya

Reputation: 21

The below code will help to sort the list generated by propertyselector tag

<sortlist property="my.sorted.list" value="${my.list}"
             delimiter="," />
<echo message="${my.sorted.list}" />

Upvotes: 0

Dolda2000
Dolda2000

Reputation: 25855

Indeed. Java properties are represented with a java.util.Hashtable, and as you surely know, hash tables do not preserve order. You simply cannot do what you want with a properties file.

If those "projects" that you state you want to build in order are in turn Ant projects, you may want to consider moving their tasks to your main build-file instead, and simply enforce the proper building order using normal Ant dependencies.

Upvotes: 1

Related Questions