ant Experten: Wie verwaltet man mehrere Projekte mit einer build.xml?

[Sholvar]

Meine Projekte werden jetzt langsam zuviel. Aber für alle möchte ich die selben Ant-Anwendungen ausführen und nach Möglichkeit nicht in jedem Projektordner eine extra build.xml haben, die ich dann alle durchgehen muss, wenn ich mich mal für ne Änderung entscheide.

Ich hab schon verschiedenes probiert, aber ich finde keine ordentliche Variante dafür.

Gibt es etwas was einen (ungefähren!!!) Aufbau wie das folgende ermöglicht:

<allgemein blubb>
  //hier alles was in jedem Projekt ausgeführt werden soll
</allgemein>
<project name="abc" tue="blubb" /> //macht nur die default sachen
<project name ="def" tue="blubb" >
  //zusätzliches zeug zu den defaultsachen
</project>
<project name="ghi" tue="blubb" /> //macht auch nur die default sachen

Wie würdet ihr es sonst machen?

 

[Ebola_inaktiv]

Das project Tag ist eindeutig. Man kann pro build file nur ein Project definieren, aber das ist quasi egal da man die targets ja beliebig kaskadieren kann. Und wenn der Buildpath nicht auf die anderen Projekte verweisen kann, dann kann man auch absolute pfade verwenden.

Die von Dir vorgeschlagene Syntax wäre aber auch cool.

Aber wofür musst Du denn unterschiedliche Projekte gleichzeitig builden?

Gruß
Ebola

 

[drwilly]

Also ansich is der Sinn von Ant für jedes Projekt eine build.xml zu haben.
Allerdings frage ich mich, was du denn da alles für deine projekte ändern willst/musst?

 

[killerchicken_inaktiv]

build.xml files autogenerieren mit einem kleinen Script -> fertig.

 

[Sholvar]

Beim Anlegen eines neuen Scripts wird die build.xml autogeneriert. Das ist schon richtig. Aber es geht ja darum, Änderungen nicht in zig Dateien ausführen zu müssen. Wahrscheinlich wird mir aber wohl nix anderes übrig bleiben :/
Wenn man so'n Skript schreibt und mit
$ php script.php
ausführt, wie kriegt man dann Parameter rein. Genauso wie beim Shellscript hinten ranhängen oder wie im Browser mit Fragezeichen und Ampersand?

@Ebola: Wir modularisieren hier alles für maximale skalierbarkeit. Und das da kein Programmierer auf dumme Gedanken kommt, werden die Module nicht in einem Gesamtprojekt abgelegt sondern getrennt verwaltet. Hat auch jedes Projekt sein eigenes Repository usw. Bei der Verwaltung muss ich natürlich sehen, dass ich das nach Möglichkeit umgangen kriege

 

[Shihatsu]

sagen wir $buildroot ist d:/dev/bla, src ist ${build_root}/src,
dann kommst du mit $buildroot/../blub in d:/dev/blub

 

[voelkerballtier]

ich kenn mich mit ant zwar nicht wirklich aus, aber man kann da doch garantiert alle mögliche programme und skripte beim build aufrufen. Warum schreibst du also nicht ein allgemeines build.xml, was dann einfach von allen projekten aus deren build aufgerufen wird? oder versteh ich hier irgendwie was falsch?

 

[killerchicken_inaktiv]

Original geschrieben von Sholvar
Beim Anlegen eines neuen Scripts wird die build.xml autogeneriert. Das ist schon richtig. Aber es geht ja darum, Änderungen nicht in zig Dateien ausführen zu müssen. Wahrscheinlich wird mir aber wohl nix anderes übrig bleiben :/

Was ich meinte ist einfach, dass du ein Script schreiben sollst, was die ganzen build.xml Dateien aus einem Template autogeneriert. Wenn sich dann am Template was ändert, rufst du das Script nochmal auf, und hast alle Dateien aktualisiert.

 

[Shihatsu]

Original geschrieben von voelkerballtier
ich kenn mich mit ant zwar nicht wirklich aus, aber man kann da doch garantiert alle mögliche programme und skripte beim build aufrufen. Warum schreibst du also nicht ein allgemeines build.xml, was dann einfach von allen projekten aus deren build aufgerufen wird? oder versteh ich hier irgendwie was falsch?

nein, da verstehste nix falsch, genauso geht es. man baut sich ein project, in das packt man alles was die projekte gemeinsam haben sollen, dann ruft man per direkter pfadangabe (siehe mein post) die projektspezifischen builds auf und packt, wenn man denn will, alle jars in ein gemeinsames war oder ear. ist mit ant aber nicht soo komfortabel. ich würde mir dafür mal maven anschauen. kann bei komplexeren geschichten deutlich mehr als ant, unterstützt wunderbar bei verteilten repositorys, man kann automatisiertes testen viel einfacher einbauen als mit ant, und ist an sich das ausgereiftere system. natürlich erkauft man sich das mit deutlich erhöhter komplexität.
p.s.: der weg den kc vorschlägt ist natürlich auch immer eine möglichkeit. meinen und seinen vorschlag kann man dazu auch noch verbinden, dir stehen viele wege offen. komplex und fehleranfällig ist jedoch jeder dieser wege, nicht umsonst sind ant builds eigentlich projektspezifisch

 

[Sholvar]

alle Fragen zu maven (das tool sieht wirklich auf den ersten blick ein bisschen besser aus als ant):

Funktioniert maven auch mit PHP?


Dieses mehrprojektieren geht also über die <module> tags. Kann ich das da so definieren, dass alle allgemeinen Sachen in der übergeordneten pom.xml stehen? Muss dann wirklich noch was in der projektspezifischen pom stehen?

 

[Ebola_inaktiv]

Du kannst doch pro Projekt ein target definieren und gibst die PFad angaben absolut an oder so wie Shihatsu vorgeschlagen hat.

Dann hast Du doch Deine Anforderungen abgedeckt.

Gruß
Ebola