Файл свойств читается в правильном порядке.Вы можете проверить это, просто вставив повторяющиеся свойства и посмотрев, какие из них определены.Вот build.properties:
dup.prop = foo
dup.prop = bar
А вот мой Ant-скрипт:
<project>
<property file="build.properties"/>
<echo>Dup.prop is set to "${dup.prop}".</echo>
</project>
Запустив это, я получу:
Dup.prop is set to "foo".
Это потому, что значение foo определяется первым в build.properies, и как только свойство определено, его нельзя (легко) изменить.
То, что вы пытаетесь сделать, - это получить доступ к свойствам вПорядок они определены.Это не гарантируется, потому что свойства хранятся в хэше.
Вы упоминаете подпроекты, и эти подпроекты должны создаваться в определенном порядке.К сожалению, трудно сказать точно, в чем может быть проблема, поскольку вы не дали нам краткое описание вашей реальной проблемы и некоторые примеры сценариев сборки для проектов и подпроектов.
Во-первых, Ant - это язык матрицы построения , что означает, что он имеет иерархию зависимостей.Самая большая проблема, с которой сталкиваются разработчики, - это попытка заставить языки матриц сборки выполняться в определенном порядке.Вы должны указать иерархию зависимостей в ваших файлах build.xml (и чем их меньше, тем легче Ant сделать все правильно).
Если подпроект "B" зависит от файла JAR в подпроекте "A", то в сценарии Ant подпроекта "B" должна быть зависимость от подпроекта "A" jarbuild.
<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>
В приведенном выше build.xml для проекта "B" я зависел от некоторого файла JAR, который создает проект "A", прежде чем я смогу скомпилировать проект "B".Поэтому моя задача compile зависит от build-jar, который будет создавать JAR-файл Target "A".Чтобы эта задача снова и снова не создавала флягу Project "A", я использую <condition> в качестве теста, чтобы проверить, существует ли эта фляга.Если это уже произойдет, я не перестраиваю флягу.
В этом случае:
- Вызов цели "compile".Эта цель понимает, что это зависит от цели "build-jar".
- До выполнения цели "compile".Сначала вызывается цель "build-jar".
- Цель "build-jar" зависит от цели "test.if.jar.exists".
- Перед выполнением "build-jar",он вызывает Target "test.if.jar.exists"
- В Target "test.if.jar.exists", если jar уже существует, будет установлено свойство
jar.exists. - Теперь цель "build-jar" активна и проверяет, установлено ли свойство
jar.exists.Если это так, цель не будет выполнена. - Наконец, элемент управления возвращается к цели "compile", которая затем выполняется.
Здесь я не применяю порядок напрямую.Вместо этого у меня просто есть иерархия зависимостей, которую я указываю, и я позволяю Ant точно определить, что делать.
Если проблемы с зависимыми банками являются большой проблемой, вы также можете изучить Ivy ,Плющ позволяет вам создать Jar Repository .Ваши проекты, которые создают JAR-файлы, от которых зависят остальные ваши проекты, могут получить необходимые JAR-файлы из этого хранилища.Это очень похоже на Maven.Фактически, Ant с Ivy может использовать репозитории Maven.Мы используем Artifactory , локальный менеджер репозитория Maven, для наших проектов Ant.
Вы также можете попробовать задачу <subant>, которая позволяет вам указать buildpath , который позволит вам сказать построить подпроект "A" перед подпроектом "B" .Вы можете определить buildpath в другом файле Ant XML, который может зависеть от клиента, а затем использовать <import>, чтобы импортировать путь сборки для этого проекта.