web-dev-qa-db-ger.com

Wie spezifiziere ich die Verteilung von maven im gesamten Management?

Ich versuche herauszufinden, wie viele (über 50) maven2-Projekte organisiert werden können, damit sie in einem zentralen Nexus-Repository bereitgestellt werden können. Wenn Sie das Ziel mvn deploy Verwenden, müssen Sie das Ziel im Tag distributionManagement wie folgt angeben:

<distributionManagement>
   <repository>
      <id>nexus-site</id>
        <url>http://central_nexus/server</url>
   </repository>
</distributionManagement>

Jetzt möchte ich nicht, dass jede einzelne pom.xml (von diesen 50+) diesen Block immer und immer wieder enthält. Meine erste wäre die Datei settings.xml, Aber es scheint nicht möglich zu sein, sie dort zu definieren. Die erste Frage wäre also, warum das so ist. Wenn es möglich wäre, könnte ich es in der settings.xml in der maven2-Distribution angeben, die an alle Entwickler verteilt werden könnte.

Die einzige mögliche Lösung, die ich gefunden habe, war, ein organisationsweites Master-POM-Projekt zu erstellen, das diese Einstellungen enthält, und alle anderen pom.xml-Dateien über das <parent> - Tag von diesem Master-POM abhängig zu machen. In Multimodul-Builds sieht das jedoch etwas seltsam aus:

- master configuration POM (pm)
- Project 1 parent pom (p1 with module 1 and module 2 as modules)
    - Project 1 module pom (with pm as parent)
    - Project 2 module pom (with pm as parent)

Normalerweise lese ich in allen Dokumentationen, dass das Modul poms das übergeordnete pom verwenden soll, nicht irgendein anderes. Nach dem Lesen der Maven-Website zu Inheritance v. Aggregation steht jedoch fest, dass dies tatsächlich möglich ist.

Ein Problem, das ich gefunden habe, war die Generierung der Maven-Site, die anscheinend Probleme mit diesem Setup hat (Module werden nicht korrekt verknüpft, wenn sie keinen direkten Rückverweis haben).

Also, ist das ein gültiger Ansatz? Gibt es eine andere, offensichtlichere und einfachere Lösung für das Problem?

100
mglauche

Die beste Lösung hierfür ist, ein einfaches übergeordnetes POM-Dateiprojekt (mit dem Paket "POM") generisch für alle Projekte Ihrer Organisation zu erstellen.

<?xml version="1.0" encoding="UTF-8"?>
<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/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>your.company</groupId>
    <artifactId>company-parent</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>pom</packaging>

    <distributionManagement>
        <repository>
            <id>nexus-site</id>
            <url>http://central_nexus/server</url>
        </repository>
    </distributionManagement>

</project>

Dies kann erstellt, freigegeben und auf Ihrem lokalen Nexus bereitgestellt werden, sodass jeder Zugriff auf sein Artefakt hat.

Fügen Sie nun für alle Projekte, die Sie verwenden möchten, einfach diesen Abschnitt hinzu:

<parent>
  <groupId>your.company</groupId>
  <artifactId>company-parent</artifactId>
  <version>1.0.0</version>
</parent>

Mit dieser Lösung können Sie alle Projekte Ihres Unternehmens auf einfache Weise um weitere gemeinsame Dinge ergänzen. Wenn Sie beispielsweise Ihre JUnit-Nutzung auf eine bestimmte Version standardisieren möchten, ist dies der perfekte Ort dafür.

Wenn Sie Projekte haben, die Strukturen mit mehreren Modulen verwenden, die über ein eigenes übergeordnetes Element verfügen, unterstützt Maven auch die Verkettung der Vererbung, sodass es durchaus akzeptabel ist, die übergeordnete POM-Datei Ihres Projekts auf die übergeordnete POM-Datei Ihres Unternehmens zu verweisen und die untergeordneten Module des Projekts nicht einmal auf Ihre zu achten Muttergesellschaft des Unternehmens.

Aus Ihrer Beispielprojektstruktur geht hervor, dass Sie versuchen, Ihr übergeordnetes Projekt auf die gleiche Ebene wie Ihr Aggregator-POM zu setzen. Wenn Ihr Projekt ein eigenes übergeordnetes Element benötigt, ist der beste Ansatz, den ich gefunden habe, das übergeordnete Element auf der gleichen Ebene wie die übrigen Module einzuschließen und Ihre Aggregator-Datei pom.xml im Stammverzeichnis zu haben, in dem sich alle Verzeichnisse Ihrer Module befinden.

- pom.xml (aggregator)
    - project-parent
    - project-module1
    - project-module2

Mit dieser Struktur fügen Sie Ihr übergeordnetes Modul in den Aggregator ein und erstellen alles mit einem mvn install aus dem Stammverzeichnis.

Wir verwenden diese exakte Lösung in meiner Organisation und sie hat sich bewährt und für uns ganz gut funktioniert.

136
Jesse Webb

Es ist kein Eltern-POM erforderlich.

Sie können den DistributionManagement-Teil vollständig in Ihren POMs weglassen und entweder auf Ihrem Build-Server oder in settings.xml festlegen.

Um dies auf dem Build-Server zu tun, übergeben Sie einfach den Befehl mvn:

-DaltSnapshotDeploymentRepository=snapshots::default::https://YOUR_NEXUS_URL/snapshots
-DaltReleaseDeploymentRepository=snapshots::default::https://YOUR_NEXUS_URL/releases

Siehe https://maven.Apache.org/plugins/maven-deploy-plugin/deploy-mojo.html für Details, welche Optionen eingestellt werden können.

Sie können dies auch in Ihrem settings.xml Einstellen.

Erstellen Sie dort einfach ein Profil, das aktiviert ist und die Eigenschaft enthält.

Beispiel settings.xml:

<settings>
[...]
  <profiles>
    <profile>
      <id>nexus</id>
      <properties>
        <altSnapshotDeploymentRepository>snapshots::default::https://YOUR_NEXUS_URL/snapshots</altSnapshotDeploymentRepository>
        <altReleaseDeploymentRepository>releases::default::https://YOUR_NEXUS_URL/releases</altReleaseDeploymentRepository>
      </properties>
    </profile>
  </profiles>

  <activeProfiles>
    <activeProfile>nexus</activeProfile>
  </activeProfiles>

</settings>

Stellen Sie sicher, dass sich die Anmeldeinformationen für "Snapshots" und "Releases" im Abschnitt <servers> Ihrer settings.xml befinden

8
Michael Wyraz