Ant-Anpassung

15/02/2017 - 09:53 von ole-usenet-spam | Report spam
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/starjav...master/pal
 

Lesen sie die antworten

#1 Lothar Kimmeringer
15/02/2017 - 22:08 | Warnen spam
Оlе Ѕtrеісhеr wrote:

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.

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}"/>



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.

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
Lothar Kimmeringer E-Mail:
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

Ähnliche fragen