Ant-Anpassung

[Оlе Ѕtrеісhеr]

Hallo Gruppe,

nicht direkt ein Java-Thema, aber zur Grauzone gehörend: (Wie) kann ich
einen neuen Typ/Task über die Kommandozeile definieren? Hintergrund: Ich möchte
ein Projekt bauen, mit minimalen Änderungen am build.xml. Das Project
[1] besitzt einen neuen Type "extclasspath", der für meine Zwecke auf
"path" gemappt werden kann. Sowas funktioniert ohne Probleme in der build.xml.

<typedef name="extclasspath" classname="org.apache.tools.ant.types.Path"/>

Kann ich das auch irgendwie ohne Änderung build.xml erreichen? Der Versuch

$ ant -Dextclasspath=org.apache.tools.ant.types.Path ...

schlägt leider fehl. Gibt es eine andere Möglichkeit?

Zweite Frage: Das Orginal-build.xml versucht grundsätzlich, die jars zu
signieren:

<signjar jar="${dist.lib.pkg}/${name}.jar"
alias="${webstart.alias}"
keystore="${webstart.keystore}"
keypass="${webstart.keypass}"
storepass="${webstart.storepass}"/>

was nicht funktioniert, weil ich keine Keys habe, und auch für meine
Zwecke gar nicht notwendig ist. Kann ich das irgendwie verhindern, indem
ich signjar auf eine No-Op "umbiege" (und gibt es eine passende No-Op in
Ant)? build.xml patchen ist irgendwie nicht so eine prickelnde Sache...

Schöne Grüße

Ole

[1] https://github.com/Starlink/starjava/tree/master/pal

[Lothar Kimmeringer]

Post by Оlе Ѕtrеісhеr
nicht direkt ein Java-Thema, aber zur Grauzone gehörend: (Wie) kann ich
einen neuen Typ/Task über die Kommandozeile definieren? Hintergrund: Ich möchte
ein Projekt bauen, mit minimalen Änderungen am build.xml. Das Project
[1] besitzt einen neuen Type "extclasspath", der für meine Zwecke auf
"path" gemappt werden kann. Sowas funktioniert ohne Probleme in der build.xml.
<typedef name="extclasspath" classname="org.apache.tools.ant.types.Path"/>
Kann ich das auch irgendwie ohne Änderung build.xml erreichen? Der Versuch
$ ant -Dextclasspath=org.apache.tools.ant.types.Path ...

Ist mir jetzt nicht wirklich bekannt, aber was du pruefen kannst
ist das Erstellen einer eigenen build.xml, in der du das definierst
und von dort aus auf das andere build.xml zugreifst und den ent-
sprechenden Target startest.

Ob ein typedef an den Sub-Ant weitergereicht wird, weiss ich aller-
dings nicht, da es in
https://ant.apache.org/manual/Tasks/ant.html
nicht erwaehnt wird. Properties werden aber durchgereicht (steuerbar)
Das Setzen von Typedefs per System-Property scheint nicht moeglich
zu sein, zumindest wird in
https://ant.apache.org/manual/Tasks/typedef.html
nichts derartiges erwaehnt. Durch die Moeglichkeit, weiterer
Parameter waere das in Properties-Syntax auch ein bisschen schwer,
glaube ich.

Post by Оlе Ѕtrеісhеr
Zweite Frage: Das Orginal-build.xml versucht grundsätzlich, die jars zu
<signjar jar="${dist.lib.pkg}/${name}.jar"
alias="${webstart.alias}"
keystore="${webstart.keystore}"
keypass="${webstart.keypass}"
storepass="${webstart.storepass}"/>

Das duerfte erforderlich sein, weil ja die Webstart-Erstellung
alle Permissions will und das von der JVM nur gewaehrt wird,
wenn ein signiertes Jar hat, soweit ich weiss.

Post by Оlе Ѕtrеісhеr
was nicht funktioniert, weil ich keine Keys habe, und auch für meine
Zwecke gar nicht notwendig ist. Kann ich das irgendwie verhindern, indem
ich signjar auf eine No-Op "umbiege" (und gibt es eine passende No-Op in
Ant)? build.xml patchen ist irgendwie nicht so eine prickelnde Sache...

Was spricht gehen den target install-runonly? Das ueberspringt,
soweit ich das sehe, das Erzeugen des Jars komplett.


Gruesse, Lothar