Meiner aktuellen Build-Datei hat folgende wiederholende Aufgaben erzeugen:Dynamisch JAR-Dateien basierend auf Paketnamen mit ANT
<jar jarfile="${build.lib}/${prefix}-foo.jar">
<fileset dir="${build.classes}">
<include name="com/a/c/foo/**"/>
</fileset>
</jar>
<jar jarfile="${build.lib}/${prefix}-bar.jar">
<fileset dir="${build.classes}">
<include name="com/a/c/bar/**"/>
</fileset>
</jar>
... etc. Das Problem ist, dass die build.xml muss für jedes neues Paket geändert werden oder für jedes neue Unterprojekt. Dies ist ein häufiges Vorkommnis, wo ich arbeite.
Ich möchte dies durch Logik ersetzen, die dynamisch die JARs und ihre Dateinamen basierend auf einem "root" -Paket generiert. So könnte ich zum Beispiel das root-Paket als com/a/c festlegen, und alle Pakete direkt unter diesem Paket erhalten ihre eigene JAR. Beachten Sie, dass alle Pakete unter "foo" oder "bar" nur Teil von "foo.jar" oder "bar.jar" sind.
Ich suchte nach Schleifenlogikaufgaben für ANT. Ich habe einen in jedem ant-contrib und JWare/AntXtras gefunden, aber ich konnte nicht wie gewünscht arbeiten.
Dies scheint wie eine Art ungerade Anforderung. Kannst du genauer erklären, warum ein einzelnes Glas nicht für deine Zwecke geeignet ist? – Jherico
Ich stimme zu, es ist definitiv aus dem linken Bereich. Wir haben ein "Basisglas" für alle gängigen Apis. Von dort aus könnte jede JAR in einer anderen Linux-Umgebung mit dem Basis-Jar platziert werden. Außerdem möchten die meisten unserer Kunden nur ein oder zwei Gläser ersetzen, die ein kleines Stück der Anwendung enthalten, anstatt alles zu ersetzen. –