Я разработал решение, которое создает jar-файл, содержащий наши многократно используемые сценарии сборки в каталоге, например com / example / ant / sharedbuild, который можно импортировать в Ant 1.8:
<project>
<import>
<javaresource name="com/example/ant/sharedbuild/java.xml">
<classpath location="../../../../target/ant-shared-build.jar" />
</javaresource>
</import>
</project>
В моем случае это определяет все «публичные» цели для проекта для сборки на основе Java.
Синтаксис немного многословен, особенно когда я добавляю все больше и больше включаемых файлов (скажем, чтобы добавитьвозможность создания OSGi jar).Добавив файл antlib.xml, который содержит комбинацию macrodef и scriptdef, в файл jar (в том же каталоге, что и общие сценарии сборки), файл сборки теперь может выглядеть следующим образом (и теперь также создается пакет jar OSGi):
<project xmlns:build="antlib:com.example.ant.sharedbuild">
<taskdef uri="antlib:com.example.ant.sharedbuild"
classpath="../../../../target/ant-shared-build.jar" />
<build:build using="java, jar, bundle" />
</project>
К сожалению, я не могу поделиться кодом в macrodef или scriptdef, но на самом деле это не сложно: маленький javascript для анализа атрибута using и зацикливания каждого из них, получения имени файла изи импортирую.
Я ссылаюсь на файл jar в фиксированном месте (относительно моего проекта) на моем жестком диске.Я думаю, что мы можем сделать лучше.В идеале я хотел бы получить (версионный!) Файл jar из центрального расположения.Так как мы уже используем Ivy (с HTTP-репозиторием), мы можем опубликовать там файл jar (опять же, с версией) и получить его прямо оттуда:
<project xmlns:build="antlib:com.example.ant.sharedbuild">
<property name="ant.shared.build.jar.file"
location="${user.home}/ant/ant-shared-build-1.5.3.jar" />
<get src="http://repo.example.com/.../ant-shared-build-1.5.3.jar"
dest="${ant.shared.build.jar.file}"
skipexisting="true" />
<taskdef uri="antlib:com.example.ant.sharedbuild"
classpath="${ant.shared.build.jar.file}" />
<build:build using="java, jar, bundle" />
</project>
Есть некоторые проблемы с этим:
- Он снова становится многословным.
- Многословие повторяется для каждого build.xml.
- Существует много повторяющихся шаблонов, особенно номер версии.
Чтобы устранить эти проблемы, в каждом каталоге, содержащем build.xml, у меня также есть файл bootstrap.xml (имя на самом деле не имеет значения).Каждый файл build.xml затем включает в себя этот файл:
<project xmlns:build="antlib:com.example.ant.sharedbuild">
<include file="bootstrap.xml" />
<build:build using="java, jar, bundle" />
</project>
Каждый файл bootstrap.xml, как минимум, включает в себя родительский файл bootstrap.xml:
<project>
<include file="../bootstrap.xml" />
</project>
Bootstrap.xml верхнего уровня.(корень), затем выполняет работу по получению jar-файла и созданию пользовательских задач, как указано выше:
<project>
<property name="ant.shared.build.version"
value="1.5.3" />
<property name="ant.shared.build.jar.filename"
value="ant-shared-build-${ant.shared.build.version}.jar" />
<property name="ant.shared.build.jar.file"
location="${user.home}/ant/${ant.shared.build.jar.filename}" />
<get src="http://repo.example.com/.../${ant.shared.build.jar.filename}"
dest="${ant.shared.build.jar.file}"
skipexisting="true" />
<taskdef uri="antlib:com.example.ant.sharedbuild"
classpath="${ant.shared.build.jar.file}" />
</project>
Хотя это не имеет прямого отношения к вопросу, на самом деле я перерабатываю macrodef и scriptdef впользовательская задача муравья, потому что я хочу иметь возможность поддерживать синтаксис, который выглядит следующим образом:
<project xmlns:build="antlib:com.example.ant.sharedbuild">
<include file="bootstrap.xml" />
<build:build>
<using>
<java />
<bundle>
<manifest>
Import-Package: *,org.joda.time;version="[1.6.0,1.6.0]"
Bundle-Activator: com.example.time.impl.Activator
</manifest>
</bundle>
</using>
</build:build>
</project>
Я должен отметить, что просто создание распространяемой сборки не означает, что она будет полезна.Вам все еще нужно потратить время и усилия на создание связной, модульной, последовательной реализации в соответствии с дизайном схожих характеристик.Это более важно, так как вам нужно обмениваться сценариями между проектами, командами, организационными границами и т. Д.
В заключение, создав файл JAR с номером версии, который можно распространять независимо от конкретногорасположение файла или инструмент SCM, мы можем получить реальные общие, но воспроизводимые сборки.