Maven Multimodule -Projektzusammensetzung in Bezug auf Abhängigkeiten zur Teilen von Abhängigkeiten

Question

Es gibt ein paar ähnliche Fragen, aber nichts dergleichen. Wie gehen Sie mit dieser Situation um (typisches Szenario):

Ein Projekt von 8-11 Kinderprojekten mit einem Eltern-Artefakt/-projekt und einem Hauptprojekt, bei dem diese anderen hauptsächlich als Module verwendet/deklariert.

Das Problem ist, dass alle Projekte "streng" nur die gemeinsamen Abhängigkeiten teilen, wie testng, logging, apache commons and stuff. Aber immer wie 3 von ihnen verwenden 50-60% der gleichen spezifischen DEPs (Apache-Chemistry, Jackrabbit, Abdera usw.). Weitere 2-3 verwenden auch 50-60% derselben, aber unterschiedlichen Abhängigkeiten. Und der Hauptdarsteller verwendet viele der gleichen DEPs.

Ich kann diese "nicht streng" geteilten DEPs nicht in das Elternprojekt einfügen, damit andere sie erben können. So werden also nur die gemeinsamen DEPs vererbt. Und es gibt unzählige doppelte Abhängigkeiten. Und ich kann ihre Versionen nur über verwalten <dependencyManagement>.

Eine andere Option ist, dass Elternpom die meisten Abhängigkeiten enthalten, aber Kinderprojekte erben auch diejenigen, die sie nicht benötigen.

Ich könnte mehr als 1 Elternprojekt haben, aber es fühlt sich nicht richtig an. Auch die Vererbung vom Elternprojekt könnte Albtraum sein, da Sie nicht wissen, welche Abhängigkeiten das Projekt benötigt, wenn Sie die Eltern -POM -Definition nicht ordnungsgemäß dokumentieren/kommentieren.

Eine andere Möglichkeit besteht darin, POM -Artefakte zu erstellen, die nur als Abhängigkeitsbehälter dienen - sie deklarieren bestimmte Gruppen von Abhängigkeiten, sodass Module nur deklarieren, um transitive Abhängigkeiten zu gewinnen. Aber hey, möchtest du eine Art von Bereitstellung und begehen

OneDePartifact Deklaration jackrabit, abdera, chemistry

Ein weiterer departifakter Deklarieren htmlcleaner, google-api, tika

Dritterdepartifakt deklarieren spring, httpclient, selenium

Es ist ein großes Durcheinander, ich bin mir nicht sicher, ob ich benutze <dependencyManagement> Richtig, es scheint nur für die Verwaltung von Abhängigkeitsversionen nützlich zu sein.

Ich dachte darüber nach, meine App -Entwicklung an "Maven Multimodule Design" anzupassen. Wenn Sie jedoch Spring Services/Beans erstellen möchten, die nur verschiedene Bibliotheken verwenden, implementieren Sie sie nicht in einem anderen Modul, nur weil sie Bibliothek verwenden, die andere Modul auch verwendet :-)

Answer 1

Maven 3.1 sollte dieses Problem durch Einführung von "Mixins" lösen. In der Zwischenzeit scheint es, dass ich die meisten erforderlichen Funktionen durch die ordnungsgemäße Verwendung von Profilen erhalten kann, wie ich in diesem Blog -Beitrag beschrieben habe:

http://weblogs.java.net/blog/fabriziogiudici/archive/2011/07/19/maven-pom-composition-means-profiles

Bitte lassen Sie mich wissen, ob Sie es nützlich finden.

Answer 2

Ich weiß, dass Sie gesagt haben, es könnte ein Albtraum sein, aber ich fühle, dass Vererbung zwischen Ihren Elternpoms der richtige Weg ist.

Ich beschreibe eine gute Multi-Modul-Projektstruktur in Diese Antwort. Es beschreibt auch die Vererbung eines Aggregators und der Elternketten.

Einige Dinge, die Ihnen helfen, die Dinge organisiert und gesund zu halten ...

• Verwenden Sie gute Namenskonventionen; Rufen Sie nicht nur die Elternprojekte an parent1 und parent2. Verwenden Sie Namen, die beschreiben, welche Art von Abhängigkeiten und anderen Dingen sie konfigurieren, sodass es für Menschen intuitiv ist, zu wissen, welche sie verwenden müssen.
• Verwenden Sie die Feature von Mavens Release/Bereitstellung, damit diese in Ihrem Repo ordnungsgemäß versioniert werden und immer festgelegte Versionsartifakte verweisen. Die Verwendung von Snapshots ist der erste Schritt, um deterministische, reproduzierbare Builds zu haben. Das Debuggen von Problemen, wenn sich die Dinge im Fliegen ändern, ist sehr schwierig.
• Verlassen Sie sich nicht auf eine pom.xml -Datei, um zu wissen, welche Abhängigkeiten Ihr Projekt benötigt. Dies führt dazu, dass Sie Erbschaft und andere Dinge wie benutzerdefinierte Profile vermeiden. Sie sollten die verwenden Maven-Abhängigkeits-Plugin um diese Analyseaufgaben auszuführen. Es gibt Befehle wie mvn dependency:tree Dies zeigt Ihnen alle Abhängigkeiten eines Projekts und mvn dependency:analyze Das zeigt Ihnen ungenutzte Abhängigkeiten.

Hoffentlich scheint mit diesem Rat die Erbschaft der Elternpom -Datei nicht so kompliziert und alptraumhaft zu sein. Viel Glück!

Answer 3

Wenn es sich hauptsächlich um die Kontrolle der Version (Nummer) befindet

Elternteil

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>foo.bar</groupId>
    <artifactId>maven-parent</artifactId>
    <version>0.0.1</version>
    <packaging>pom</packaging>

    <properties>
        <log4j.version>1.2.16</log4j.version>
    </properties>

</project>

Kind

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <artifactId>maven-parent</artifactId>
        <groupId>foo.bar</groupId>
        <version>0.0.1</version>
    </parent>

    <groupId>foo.bar</groupId>
    <artifactId>maven-child</artifactId>
    <version>0.0.1-SNAPSHOT</version>

    <dependencies>
        <dependency>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
            <version>${log4j.version}</version>
        </dependency>
    </dependencies>

</project>

Dies ist eine einfache Lösung, mit der Sie bestimmte Projektabhängigkeiten mit konsistenten Versionsnummern angeben können.