Comment paramétrer un chemin dans ANT ?

Question

J'ai défini les éléments suivants dans un fichier appelé build-dependencies.xml

<?xml version="1.0" encoding="UTF-8"?>
<project name="build-dependencies">
  ...
  <path id="common-jars">
    <fileset file="artifacts/project-1/jar/some*.jar" />
    <fileset file="artifacts/project-2/jar/someother*.jar" />
  </path>
  ...
</project>

Je l'inclus en haut de mon construire.xml fichier. J'ai maintenant besoin de faire du dossier des artefacts un paramètre afin qu'il puisse être modifié pendant l'exécution de différentes cibles. En ayant ce...

<?xml version="1.0" encoding="UTF-8"?>
<project name="build-dependencies">
  ...
  <path id="common-jars">
    <fileset file="${artifacts}/project-1/jar/some*.jar" />
    <fileset file="${artifacts}/project-2/jar/someother*.jar" />
  </path>
  ...
</project>

...et la définition d'une propriété "artefacts" (et sa modification) dans la cible ne fonctionne pas car il semble que la substitution de propriété se produise lorsque le chemin est défini en build-dependencies.xml

Comment puis-je résoudre ce problème ? J'ai pensé à une macro paramétrée et à l'appeler avant que le chemin ne soit réellement utilisé, mais cela ne semble pas élégant. Quelque chose comme ceci :

<macrodef name="create-common-jars">
  <attribute name="artifacts"/>
  <sequential>
    <path id="common-jars">
      <fileset file="@{artifacts}/project-1/jar/some*.jar" />
      <fileset file="@{artifacts}/project-2/jar/someother*.jar" />
    </path>
  </sequential>
</macrodef>

EDIT : Ivy et les paramètres de ligne de commande ne sont pas une option.

Answer 1

Vous ne voulez pas d'un chemin paramétré. Vous voulez un Jeu de motifs . Vous pouvez définir le jeu de motifs au niveau supérieur, puis y faire référence dans les cibles individuelles lorsque vous en avez besoin. Pour votre exemple :

<?xml version="1.0" encoding="UTF-8"?>
<project name="build-dependencies">
  ...
  <patternset id="common-jars">
    <include name="project-1/jar/some*.jar" />
    <include name="project-2/jar/someother*.jar" />
  </patternset>
  ...
  <path id="instrumented-jars">
    <fileset dir="instrumented">
      <patternset refid="common-jars" />
    </fileset>
  </path>
  ...
  <path id="standard-jars">
    <fileset dir="not-instrumented">
      <patternset refid="common-jars" />
    </fileset>
  </path>
  ...
</project>

Answer 2

Appelons votre fichier build.xml. Vous l'exécutez donc en lançant la commande ant. Dans le premier cas, les noms des artefacts sont codés en dur dans la propriété définie sur la troisième ligne ci-dessous

<?xml version="1.0" encoding="UTF-8"?>
<project name="build-dependencies">
<property name="artifacts" value="first-value" />
  ...
  <path id="common-jars">
    <fileset file="artifacts/project-1/jar/some*.jar" />
    <fileset file="artifacts/project-2/jar/someother*.jar" />
  </path>
  ...
</project>

Maintenant, quand on veut le changer et utiliser une autre valeur pour cette propriété artefacts, on exécute le script ainsi

ant -Dartifacts=new-value

Cela remplacera la valeur des artefacts codée en dur dans le fichier build.xml.

Si vous travaillez en termes de cibles ant, vous pouvez faire quelque chose de similaire, dans la cible sur la première ligne, définissez la propriété, et si vous voulez écraser la valeur par défaut, passez la propriété comme paramètre lorsque cette cible est appelée.

Votre commentaire m'a fait penser à autre chose. Demandez à vos développeurs de créer un fichier artifacts-dir-name.xml. Il n'aura qu'une seule ligne :

<?xml version="1.0" encoding="UTF-8"?>
<project name="artifacts-file">
<property name="artifacts" value="new-value" />
</project>

Maintenant dans votre fichier build.xml, avant la ligne où la propriété des artefacts est définie, importez ce fichier ainsi :

<import file="artifacts-dir-name.xml" optional="true" />

Maintenant, dans Eclipse, si ce fichier existe, alors la propriété est lue à partir de celui-ci et artifacts est défini à "new-value", sinon la propriété est lue à partir de build.xml et est définie à "first-value". Tout ce que les développeurs doivent faire est de s'assurer que le fichier artifacts-dir-name.xml existe dans ce répertoire. Cette opération peut également être exécutée dans Eclipse.

Answer 3

Je recommande d'utiliser lierre pour gérer les dépendances de votre classpath. Ivy possède un concept intéressant appelé configurations qui vous permet de regrouper des collections d'artefacts en fonction de leur utilisation.

Voici une adaptation d'un de mes propres fichiers de construction :

<target name="retrieve" description="3rd party dependencies">
    <ivy:resolve/>

    <ivy:cachepath pathid="build.path" conf="build"/>
    <ivy:cachepath pathid="runtime.path" conf="runtime"/>
</target>

Les configurations sont gérées dans le ivy.xml (remplacerait votre build-dependencies.xml fichier)

<ivy-module version="2.0">
    <info organisation="com.myspotontheweb" module="HelloWorld"/>

    <configurations>
        <conf name="build" description="jars needed for build" />
        <conf name="runtime" extends="build" description="jars needed at runtime" />
    </configurations>

    <dependencies>
        <dependency org="org1" name="project1" rev="1.0" conf="build->default"/>
        <dependency org="org2" name="project2" rev="1.0" conf="build->default"/>
        <dependency org="org3" name="project3" rev="1.0" conf="runtime->default"/>
        <dependency org="org4" name="project4" rev="1.0" conf="runtime->default"/>
    </dependencies>
</ivy-module>

Les artefacts jar associés à chaque projet seront téléchargés et mis en cache automatiquement à partir des dépôts maven en ligne ou vous pouvez créer votre propre dépôt local pour contenir des collections d'artefacts appartenant à des utilisateurs locaux.

Answer 4

L'utilisation de variables d'environnement est-elle une option (si elles sont définies au lancement d'eclipse, elles seront prises en compte) ? Si c'est le cas, faites en sorte que chacun d'entre eux définisse ARTIFACTS et cela devrait fonctionner :

<?xml version="1.0" encoding="UTF-8"?>
<project name="build-dependencies">
  <property environment="env"/>
  <path id="common-jars">
    <fileset file="${env.ARTIFACTS}/project-1/jar/some*.jar" />
    <fileset file="${env.ARTIFACTS}/project-2/jar/someother*.jar" />
  </path>
</project>

Answer 5

OK, je pense qu'il n'y a pas d'autre moyen évident pour moi de faire ce que j'essaie de faire, à part utiliser une macro qui prend un paramètre et crée le chemin avec le dossier d'artefacts approprié.

Pour donner un peu de contexte, la raison pour laquelle j'essayais ce que je voulais est d'avoir des artefacts "instrumentés" et "non instrumentés" dans des dossiers séparés. Et dans mes "cibles", je pouvais simplement faire varier le mode des artefacts. Donc ce que je fais maintenant c'est que j'ai une macro : <initialise-build-settings artifacts-mode="instrumented" /> qui met en place tous les chemins et autres variables.

Merci pour vos réponses.