Maven (Java EE, WAR) Eigener Buildschritt - Manipulation von Dateien

[MrFox]

Liebe Java-Community,

ich habe für eine Java-EE Anwendung, die am Ende des Builds in ein WAR gepackt wird, ein Übersetzungssystem geschrieben. Dieses manipuliert u.a. während dem Build einige XHTML-Dateien des Projekts. Dies geschieht über ein selbst geschriebenes Maven-Plugin. Das Problem ist nun, dass es mir nicht gelingt, diese Manipulationen vernünftig in den Build-Prozess zu integrieren.
Wichtig ist: Die Manipulation soll nur im deployten Code vorliegen, die Working Copy des Entwicklers soll unberührt bleiben.
Ich schildere meine Lösungsansätze und die dabei auftretenden Probleme:

0. Nach dem das Maven-War-Plugin das /target-Verzeichnis zusammengestellt hat und bevor dieses Verzeichnis in das WAR gepackt wird, die Daten manipulieren. Problem: Maven erlaubt nicht, sich an dieser Stelle in den Prozess reinzuklinken.

1. Maven ein anderes Quellcodeverzeichnis angeben, und die Daten vor dem Build aus dem Quellcodeverzeichnis des Entwicklers dorthin kopieren. Während des Kopierens die Manipulationen vornehmen. Problem: Die verwendete IDE Netbeans nimmt dann das alternative Quellcodeverzeichnis als Root und zeigt nur die manipulierten Daten an.

2. Für die Zeit des Builds die originalen Quelldateiem irgendwo sichern und im Quellcodeverzeichnis alles manipulieren. Nach dem Build die Originaldaten zurückkopieren. Problem: Sehr unsauber, kann früher oder später zu Datenverlust wegen Abbruch des Builds und sehr wütenden Kollegen führen.

3. Nach dem Zusammenbau des WAR das Archiv auspacken, Manipulationen vornehmen und das Archiv wieder zusammenpacken. Problem: Maven weigert sich dann, den Schritt install oder deploy auszuführen mit dem Fehler: The packaging for this project did not assign a file to the build artifact.

4. Es muss doch möglich sein, bei einem solch komplexen Buildsystem wie Maven, sich irgendwie vernünftig in den Build-Prozess mit reinzuhängen, auch wenn man Quellcode manipulieren will...

Vielen Dank für Eure Hilfe!

 

[kama]

Erste Frage: In welcher Art manipuliert Dein Plugin die Dateien? Inhalte ersetzen ? Abgesehen davon werden EE Anwendung in EAR's verpackt...weiterhin gibt es die Life Cycle Phase: prepare-package in der man solche Dinge machen kann...
Anderes Quellverzeichnis angeben verletzt Convention over Configuration...Im target Ordner kann man Sachen ablegen die geändert wurden. Im Quellverzeichnis ändert man niemals da die in der Versionskontrolle eingecheckt sind...

 

[MrFox]

Hey, ja das Manipulieren ist Bearbeiten im Sinne von Inhalte ersetzen.
Unsere EE-Anwendung wird in ein WAR verpackt.
Es ist sehr schön, dass du mir auch nochmal runterbetest, dass meine Lösungsansätze nicht funktionieren, aber ich dachte, dass hätte ich selber schon klargemacht, dass die Ansätze nicht funktionieren.
Tatsächlich habe ich eine Lösung gefunden. Die Phase prepare-package alleine tut's nicht. Den das target-Verzeichnis wird erst im Schritt package befüllt. Aber es geht wie folgt:
1. In prepare-package zunächst manuell einen Buildschritt einfügen, der das WAR baut (und damit auch target befüllt)
2. Als ersten Schritt in package meinen eigenen Manipulationscode ausführen (der Daten im target-Verzeichnis ändert)
3. Als zweiten Schritt in package nochmal das WAR zusammenbauen, dabei aber mit dem Konfigurationstag
<warSourceExcludes>**/*</warSourceExcludes> dafür sorgen, dass das target-Verzeichnis nicht erneut befüllt wird (was ja meine Änderungen überschreiben würde)

 

[kama]

Anscheinend bist Du nicht daran interessiert wie man es richtig macht. Doppelte Ausführung des war-plugins macht keinen Sinn. Die "Lösung" ist keine Lösung sonder ein Hack.
Abgesehen davon gibt es für das Erstzen in Maven schon eine Lösung, die nennt sich "Filtering"...dafür braucht man kein eigenes Plugin.

Weiterhin kommt es mir sehr komisch vor, dass Du damit dann einen Artefakt erzeugt der lokal anders aussieht (bzw. anderen Inhalt hat) als der der deployed wird, sprich in ein Remote repository übertragen wird...

 

[MrFox]

Doch in bin sehr daran interessiert, wie man es noch besser macht. Ob die doppelte Ausführung nun Sinn macht oder nicht sei dahingestellt, sie funktioniert auf jeden Fall ohne Nachteile. Ich sehe momentan keine bessere Möglichkeit, welche siehst du?

Also die Manipulationen sind nichttrivial (XML parsen, bestimmte Elemente ändern usw.) und müssen auf jeden Fall aus meinem Maven-Plugin heraus gemacht werden. Das ist feste Rahmenbedingung.

Deine letzte Anmerkung verstehe ich nicht ganz. Beziehst du dich auf Möglichkeit Nummer 3) ?