Maven Maven distributionManagement Vererbung in child POM

[einbyte]

Hi,

ich hab hier aktuell zwei (später mehr) Systeme mit je einer "Haupt-" POM (diese referenzieren dann via <modules> die ganzen Sub- und diese die Sub-Sub-Poms (aktuell ca 60).

Der Name "Haupt-" POM, weil aus Sicht *des Systems* dieses das "höchste" ist.

Nun habe ich halt mehrere Projekte, die mehrere solcher Systeme verwenden. Ein System, also eine "Haupt-" POM, möchte ich in mehreren Projekten verwenden. Jedes System und jedes Projekt muss für sich reproduzierbar sein.

Mein naive Ansatz war, einfach eine "Über-" POM anzulegen, die die beiden Haupt-POMs referenziert.

Beispiel:

sys1/pom.xml  # "Haupt-" POM system 1 mit modules = component1 und component2
sys1/component1/pom.xml # parent = sys1
sys1/component1/module1/pom.xml # parent = component1
sys1/component1/module2/pom.xml # parent = component1
sys1/component2/module1/pom.xml # parent = component2
sys1/component2/module2/pom.xml # parent = component2

sys2/pom.xml  # "Haupt-" POM system 2 mit modules = component1 und component2
sys2/component1/pom.xml # parent = sys2
sys2/component1/module1/pom.xml # parent = component1
sys2/component1/module2/pom.xml # parent = component1
sys2/component2/module1/pom.xml # parent = component2
sys2/component2/module2/pom.xml # parent = component2

build/pom.xml  # "Über-" POM mit modules = ../sys1 und ../sys2

Komponenten und Modulnamen sind zufällig systemübergreifend eindeutig, also es gibt nicht zweimal module2 oder so. Die "Haupt-" POMs (sys*/pom.xml) haben kein parent = ../build.pom.

In diesem Beispiel könnte es jetzt noch eine zweite "Über-" POM geben, die sys1 und sys3 verwendet.

Das funktioniert soweit auch erstmal.

Je Projekt habe ich unterschiedliche <distributionManagement>. Jetzt wäre es ganz toll, wenn ich das einfach in der höchsten POM definiere und es vererbt wird.

Leider funktioniert das nicht; ich muss in der "Über-" POM und in beiden "Haupt-" POMs <distributionManagement> setzen.

Scheinbar funktioniert Vererbung von Sub-POMs nur richtig, wenn man <parent> verwendet. <parent> macht natürlich die Ortogonalität kaputt, weil ein Modul sein übergeordnetes Projekt kennen muss (wie auch immer man auf sowas kommt, ist mir schleierhaft, wäre für eine kurze Erklärung dankbar).

Da meine eine "Haupt-" POM von zwei Projekten ("Über-" POMs) verwendet wird, kann ich <parent> natürlich da nicht reinschreiben.

Ich könnte natürlich Maven auch einfach zweimal aufrufen, dann muss ich statt dreimal nur noch zweimal <distributionManagement> setzen (die "Über-" POM und auch alle anderen POMs interessieren mich nicht, ich würde sie am liebsten gar nicht deployen lassen, aber das ist scheinbar in Maven hardcoded).

Kann ich das eleganter lösen?

~/1b

 

[kama]

Was mir an der ganzen Geschichte nicht klar ist warum Du unterschiedliche distributionManagement's hast ?

Gruß
Karl Heinz

 

[einbyte]

Was mir an der ganzen Geschichte nicht klar ist warum Du unterschiedliche distributionManagement's hast ?

Weil die Projekte unabhängig von einander sind und sich kein Deployment Repository teilen.

~/1b

 

[kama]

Hm...

Die Artefakte werden Anhand der GroupId/ArtifactId/Version unterschieden und nicht im Deployment Repository... Das die Projekte unabhängig von einander sind ist eine Sache....man schaue mal in Maven Central...da sind hunder tausende Projekte drin und alle aber einem Repository ...

Da frage ich mich was Du unbeding anders machen willst und warum?

Gruß
Karl Heinz Marbaise

 

[einbyte]

man schaue mal in Maven Central...da sind hunder tausende Projekte drin und alle aber einem Repository ...
Da frage ich mich was Du unbeding anders machen willst und warum?

Unabhängigkeit (bzw. "be self-contained") ist eine Anforderung. Eigentlich auch keine so ungewöhnliche.
In Maven Central sind Open Source Pakete, ohne besondere vertragliche Garantien.

Dürft ihr eure Pakete (auf Arbeit) denn etwa dahin hochladen?!

~/1b

 

[kama]

Hm...

Unabhängigkeit (bzw. "be self-contained") ist eine Anforderung.

Unter self-contained kann man sehr viel verstehen ....kannst Du mal genau darlegen was Du damit meinst bzw. was damit erreicht werden soll?...

In Maven Central sind Open Source Pakete, ohne besondere vertragliche Garantien.

Welche Art Vertrag möchtest Du denn haben? Und Du benutzt Maven ? Auch Open Source ? Hast Du einen Vertrag ? (vor allem mit Wem ?) Verwirrt mich gerade....

Dürft ihr eure Pakete (auf Arbeit) denn etwa dahin hochladen?!

Was hat das mit self-contained zu tun ?

Gruß
Karl Heinz Marbaise

 

[einbyte]

Unter self-contained kann man sehr viel verstehen ....kannst Du mal genau darlegen was Du damit meinst bzw. was damit erreicht werden soll?...

Na ganz am Ende möchte man alles auf DVD brennen können und in 10, 15 oder 20 Jahren (je nach Projekt) noch bauen können, dabei ggf. mit Korrekturen (für Invesitionssicherheit usw).

Welche Art Vertrag möchtest Du denn haben? Und Du benutzt Maven ? Auch Open Source ? Hast Du einen Vertrag ? (vor allem mit Wem ?) Verwirrt mich gerade....

Sorry, steh gerade bisschen auf dem Schlauch, wir reden wohl aneinander vorbei. Also ihr entwickelt ja sicher auch, um am Ende irgendeinen Vertrag mit dem Kunden zu erfüllen (sei es ein Werkliefervertrag, Lizenzvertrag oder sonstwas). Da stehen ja dann in der Regel Garantien drin und/oder es gibt gesetzliche, beispielsweise Gewährleistung. Vielleicht verpflichtet man sich, schwere Fehler 2 Jahre lang zu korrigieren und in Form neuer Versionen nachzuliefern. Open Source Systeme werden dabei natürlich auch oft verwendet, so ist Maven selbst ja schon Open Source.

Wobei das Maven Projekt [ist natürlich nur ein Beispiel, vielleicht hat man Bibliotheken, Entwicklungsumgebungen...] jetzt nicht garantiert, in 10 Jahren noch zu liefern, kompatibel zu sein oder überhaupt auch nur eine Webseite zu betreiben. Also muss man das irgendwie "einpacken" und archivieren können.

Aber eigentlich wollten wir ja nicht die Anforderungen diskutieren, sondern elegante Lösungen

~/1b

 

[kama]

Hallo,

Na ganz am Ende möchte man alles auf DVD brennen können und in 10, 15 oder 20 Jahren (je nach Projekt) noch bauen können, dabei ggf. mit Korrekturen (für Invesitionssicherheit usw).

Achso Du meinst ein Escrow Kit....

Ok. Ich baue meine Software auf einen definierten System (üblicherweise ein CI System) und danach sichere ich das lokale Maven Repository (von dem Job der da gerade gelaufen ist) inkl. der Tools...JDK / Maven usw. (als ZIP/tar.gz etc.) Das Ganze kann man mithilfe einens Jenkins Jobs automatisieren...dann habe ich was da gefordert ist...Eventuell kann ich mir noch ein Script schreiben was dann den Maven Aufruf angibt (mit Offline etc.), damit man das in 10 Jahren auch noch weiß wie das geht...

So zu dem Zurück was Du da noch geschrieben hast:

Was ich bei der Ganzen Geschichte nicht verstehe ist warum du unterschiedliche distributionManagement benötigst?
Das distributionManagement definiert wohin die Artifakte transportiert werden bei einem

mvn deploy

. Das ist üblicherweise ein Repository Management System (Artifactory, Nexus, Archiva)....und davon hat nur einen....Dann gibt es eben Releases und Snapshots...

Scheinbar funktioniert Vererbung von Sub-POMs nur richtig, wenn man <parent> verwendet. <parent> macht natürlich die Ortogonalität kaputt, weil ein Modul sein übergeordnetes Projekt kennen muss (wie auch immer man auf sowas kommt, ist mir schleierhaft, wäre für eine kurze Erklärung dankbar).

Vererbung in Java funktioniert nur dann richtig wenn ich eben

XYZ extends VonDerIchErbe

hinschreibe....

Ich definiere ein Unternehmens POM..da werden dann die unterschiedlichen plugins mit Versionen angegenben, Konfigurationen für die Plugins, Lizenz Info usw. und eben distributionManagement...

Alle meine Projekt erben von dieser Unternehmens POM...Ich kann wenn ich im Unternehmen noch unterschiedliche Projekttypen habe (Web-Projekte, Batch Projekte etc.) kann ich noch eine/oder mehrere Zwischeneben mit POM einführen, die dann spezielle Ergänzungen bzgl. der Projekte macht....

Eine Parent POM ist ein eigenständiges Projekt, dass eben nur aus der POM selbst besteht.....

Eventuell Verstehe ich Deine Anforderungen noch nicht...

Gruß
Karl Heinz Marbaise

 

[einbyte]

Achso Du meinst ein Escrow Kit....

Möglich; was ist ein Escrow Kit? Der Begriff klingt recht allgemein.

Spanennd: habe nach "Escrow Kit" software gegooglet und
Dein Posting war auf der ersten Seite cool.

Scheint ein projektspezifischer Begriff zu sein.

Ok. Ich baue meine Software auf einen definierten System
(üblicherweise ein CI System) und danach sichere ich das lokale
Maven Repository (von dem Job der da gerade gelaufen ist) inkl.
der Tools...JDK / Maven usw. (als ZIP/tar.gz etc.) Das Ganze
kann man mithilfe einens Jenkins Jobs automatisieren...dann habe
ich was da gefordert ist...Eventuell kann ich mir noch ein Script
schreiben was dann den Maven Aufruf angibt (mit Offline etc.),
damit man das in 10 Jahren auch noch weiß wie das geht...

Natürlich muss das vollautomatisch sein, klar.

Deine Lösung mag manchmal reichen, aber ist nicht unbedingt
sinnvoll, weil in 10 Jahren bestimmt nicht wartbar. Angenommen,
man muss in irgendeiner Library einen kleinen Fehler korrigieren.
Dann muss man die Sourcen haben (weiß nicht, ob Maven die immer
mitholt?), die bauen können (was auch immer die nutzen, muss ja
nicht Maven sein, kann ja auch Ant sein, was man dann natürlich
auch haben muss, kann auch sonstwas brauchen). Dann muss man das
packen können und das Repository irgendwie updaten. Das geht
dann sicherlich nicht mehr automatisch.

Was ich bei der Ganzen Geschichte nicht verstehe ist warum du
unterschiedliche distributionManagement benötigst?
Das distributionManagement definiert wohin die Artifakte transportiert werden bei einem

mvn deploy

. Das ist üblicherweise ein Repository Management System (Artifactory, Nexus, Archiva)....und davon hat nur einen....Dann gibt es eben Releases und Snapshots...

Genau das ist das Problem: Maven definiert, wohin die Artifakte
transportiert werden.

Wenn das "wirkliche" Projektrepository nun ein WORM (mit
Transaktionssicherheit usw) ist oder ein remote file system(*), wo
man existierende Dateien nicht schreiben kann, funktioniert das
nicht. Dann braucht man noch einen Mechanismus, der die
Ergebnisse ablegt. Wenn man das macht, kann man aus dieser
"eigenen" Ablage aber nicht mehr so ohne weiteres bauen.

EDIT: (*) sprich, wenn das Repository eine "API" ist, und kein
Dateisystem, was sich wie ein normales lokales Filesystem
verhält.

Vererbung in Java funktioniert nur dann richtig wenn ich eben

XYZ extends VonDerIchErbe

hinschreibe....

?

Stimmt übrigens nicht, man kann IDL verwenden. Da wird das dann generiert und man muss es nicht (und kann es nicht) hinschreiben

Ich definiere ein Unternehmens POM..da werden dann die unterschiedlichen plugins mit Versionen angegenben, Konfigurationen für die Plugins, Lizenz Info usw. und eben distributionManagement...

"Unternehmens POM" klingt doch völlig unrealistisch. Wie soll man
denn eine POM für unabhängige Projekte haben können? Was ist mit
"clean room" Projekten, die nicht mit anderen interagieren
dürfen?
"Unternehmens POM" verletzt Orthogonalität und es gibt Projekte
bzw. Umfelder, wo das absolut unerwünscht ist. Überhaupt, das mag
bei kleinen Unternehmen mit nur einer Entwicklungsabteilung
vielleicht manchmal gehen, aber wie soll eine
Entwicklungsabteilung in einem Projekt mit sichere Chipkarten
sich eine POM mit einer Entwicklungsabteilung von Webentwicklern
teilen...

Alle meine Projekt erben von dieser Unternehmens POM...Ich kann
wenn ich im Unternehmen noch unterschiedliche Projekttypen habe
(Web-Projekte, Batch Projekte etc.) kann ich noch eine/oder
mehrere Zwischeneben mit POM einführen, die dann spezielle
Ergänzungen bzgl. der Projekte macht....

Genau, und der Webentwickler soll dann ein WORM Repo benutzen,
weil das Herzschrittmacherprojekt das braucht. Na die Web
Entwickler werden sich freuen. Erstmal drei Unterschriften von
den Gutachtern auf den Unbedenklichkeitsbescheinigungen holen.
Ach, Moment, wo ist der Compliance Test Report für MyWebLib 0.2?

Eventuell Verstehe ich Deine Anforderungen noch nicht...

Ich wollte eher darauf hinaus, dass es eine Vielzahl möglicher
Anforderungen gibt, je nach Projekt oder je nach Wetter.

In "der Apache Welt", falls man das so sagen darf, gelten
beispielsweise bestimmte Anforderungen wie hohe Aktualität,
einfache Benutzbarkeit, und andere nicht, wie Reproduzierbarkeit
oder formale Freigabeprozesse. Wobei es inzwischen, also seit
vielen Jahren sogar, durchaus Freigabeprozesse und Formalien
gibt, aber die müssen nicht so rechtssicher sein, wie andere,
weil man Haftungsausschlüsse machen kann, was ein
Herzschrittmacherprojekt oder die Lenkwaffensteurung nicht darf;
letzere muss vielleicht beachten, dass nicht alle Libs für
Militärzwecke lizensierbar sind oder Geld kosten.

Anforderungen können fast beliebig sein. Wenn ein Kunde dafür
bezahlt

~/1b