mvn: viele Projekte, die faktisch nur eines sind.

Die Ausgangslage

Ich bin "Integrator" in einem mittelgrossen Projekt, das aus mehreren "Komponenten" besteht. In einem normalen Fall würde man ein (hierarchisches) maven-Projekt erstellen, mit den "Komponenten" als Sub-Module. In meinem Fall wären das ca. 14 Submodule (ca. 3 JEE6-Applikationen, Modelle etc.), wobei die Submodule auch wieder in Submodule unterteilt sind. 

Das Set-Up wäre also vergleichbar mit dem Set-Up von JBoss AS.

Die Entwicklung zum Problem

Durch meine anfängliche Unerfahrenheit als Integrator liess ich mich durch Architekten und anderen Entwicklern dazu verleiten, das Projekt aufzuteilen: 

Die "Komponenten" sollen unabhängig sein, weil sie später von anderen Projekten wiederverwendet werden sollen, und auch von anderen Entwicklerteams weiterentwickelt werden.  

Was dabei rauskam: 14 Total unabhängige Projekte, mit eigenem mvn-Build und eigenem Job auf der Continous Integration (Hudson), z.T. mit eigenem CVS (sic!) Repository, die aber eine enge Kopplung via Maven-Dependencies untereinander haben. 

De-Facto handelt es sich aber um ein Projekt, die Entwickler arbeiten immer an 4-5 Projekten gleichzeitig.

Um dieses Problem zu entschärfen, habe ich alle 14 Projekte und deren Dependencies von der Continous Integration als SNAPSHOT builden lassen. So haben alle Entwickler immer die neuste Version von allem. Ausserdem habe ich die Dependencies durch ein BOM-pom (Import eines Dependency-Management) synchronisiert - was mir von den Architekten etc. prompt wieder verboten wurde, weil "Abhängigkeit". 

Dieses Set-Up hat uns aber massive Probleme mit der Aktualität der SNAPSHOT beschert. 

Ausserdem: das Release der 14 beteiligten Projekte und deren Abhängigkeiten ist eine "Integration Hell" und beschäftigt einen Entwickler 6h lang. 

Lösungsansätze

Probleme mit der Aktualität der SNAPSHOT zu entschärfen, haben wir uns überlegt, dass die Entwickler die Sub-Projekte halt releasen soll und die Abhängigkeiten von Hand in den abhängigen Projekten nachtragen soll. Auch das ist natürlich sehr fehleranfällig und sehr zeitaufwändig. 

Frage

Die Frage ist nun: gibt es ein Werkzeug, dass die Abhängigkeiten bei einem Release der 14 Projekte in den abhängigen Projekten automatisch nachführt? 

Mein (unerfahrenes) Gefühl sagt mir, dass ich hier total auf dem Holzweg bin, und die 14 Projekte eigentlich nur eines sein sollten, so wie JBoss. Wenigstens so lange, wie das Team "querbeet" daran arbeitet. 

Was aber sage ich meinen Architekten, die finden, jede "Komponente" müsse total unabhängig sein?
Und was ist mit den Projekten, die jetzt schon abhängig von einem unserer "Komponenten" sind?

Fazit und Lösung: 

Nach vielen Diskussionen (mit maven-Experten) hat sich diese Lösung herauskristallisiert, die mir eigentlich von Anfang her als Gefühl klar war (siehe oben): 

In einem solchen Set-Up sollte nur ein Maven-Projekt existieren: die 14 Teilprojekte werden module dieses Projektes, wobei diese Module wiederum sub-Module haben können. 

Das gibt keine Einschränkungen in Sachen low-coupling. 

Werden später die Module tatsächlich eigenständige Projekte, die von einem eigenen Team separat entwickelt werden, und auch einen total unabhängigen Release-Zyklus haben, können die Module leicht herausgelöst werden. 

Anders ausgedrückt: Die Zusammenfassung als maven-Projekt sagt nichts aus über die Kopplung der Software in den Modulen. Sie bildet nur den Fakt ab, dass die Module gemeinsam gebaut werden. Die Module bleiben schwach gekoppelt, unabhängig und wiederverwertbar. 

Links:

http://stackoverflow.com/a/11478970/1800814
http://stackoverflow.com/a/2837816/1800814