Jak najlepiej podzielić cele Anta między projektami?

Czy istnieje dobrze znany sposób udostępnianiaMrówka cele między projektami? Mam obecnie rozwiązanie, ale jest trochę nieeleganckie. Oto co robię do tej pory.

Mam plik o nazwieivy-tasks.xml hostowane na serwerze w naszej sieci. Ten plik zawiera, między innymi, standardowe zadania do zarządzania zależnościami projektuBluszcz. Na przykład:

<project name="ant-ivy-tasks" default="init-ivy"
         xmlns:ivy="antlib:org.apache.ivy.ant">
  ...
  <target name="ivy-download" unless="skip.ivy.download">
    <mkdir dir="${ivy.jar.dir}"/>
    <echo message="Installing ivy..."/>
    <get src="http://repo1.maven.org/maven2/org/apache/ivy/ivy/${ivy.install.version}/ivy-${ivy.install.version}.jar"
         dest="${ivy.jar.file}" usetimestamp="true"/>
  </target>

  <target name="ivy-init" depends="ivy-download"
          description="-> Defines ivy tasks and loads global settings">
    <path id="ivy.lib.path">
      <fileset dir="${ivy.jar.dir}" includes="*.jar"/>
    </path>
    <taskdef resource="org/apache/ivy/ant/antlib.xml"
             uri="antlib:org.apache.ivy.ant"
             classpathref="ivy.lib.path"/>
    <ivy:settings url="http://myserver/ivy/settings/ivysettings-user.xml"/>
  </target>
  ...
</project>

Powodem, dla którego plik jest hostowany, jest to, że janie chcieć:

Sprawdź plik w każdym projekcie, który go potrzebuje - spowoduje to duplikację, co utrudni utrzymanie celów.Niech mój build.xml zależy od wyewidencjonowania projektu z kontroli źródła - dzięki temu kompilacja będzie miała więcej XML na najwyższym poziomie, aby uzyskać dostęp do pliku.

To, co robię z tym plikiem w build.xmls moich projektów jest zgodne z:

<property name="download.dir" location="download"/>
<mkdir dir="${download.dir}"/>
<echo message="Downloading import files to ${download.dir}"/>

<get src="http://myserver/ivy/ivy-tasks.xml" dest="${download.dir}/ivy-tasks.xml" usetimestamp="true"/>
<import file="${download.dir}/ivy-tasks.xml"/>

„Brudna” część tego jest taka, że ​​muszę wykonać powyższe krokipoza celem, ponieważzadanie importu musi być na najwyższym poziomie. Ponadto nadal muszę uwzględnić ten XML we wszystkich plikach build.xml, które go potrzebują (tj. Nadal jest pewna ilość duplikacji).

Ponadto mogą istnieć dodatkowe sytuacje, w których mogę mieć wspólne zadania (inne niż Ivy), które chciałbym zaimportować. Gdybym miał zapewnić te zadania za pomocą zarządzania zależnością Ivy, nadal brałbym problemy, ponieważ do czasu rozwiązania zależności musiałbym znajdować się wewnątrz celu w moim pliku build.xml i nie można go zaimportować (z powodu do ograniczenia wymienionego powyżej).

Czy jest lepsze rozwiązanie dla tego, co próbuję osiągnąć?

questionAnswers(4)

yourAnswerToTheQuestion