it-swarm.com.de

Hosting eines Maven-Repository auf github

Ich habe eine Gabel aus einer kleinen Open-Source-Bibliothek, an der ich gerade an Github arbeite. Ich möchte es anderen Entwicklern über maven zur Verfügung stellen, aber ich möchte keinen eigenen Nexus-Server betreiben, und da es sich um einen Fork handelt, kann ich ihn nicht einfach auf oss.sonatype.org bereitstellen.

Ich würde es gerne für github bereitstellen, damit andere mit maven darauf zugreifen können. Was ist der beste Weg dies zu tun?

291
emmby

Die beste Lösung, die ich finden konnte, besteht aus diesen Schritten:

  1. Erstellen Sie einen Zweig mit dem Namen mvn-repo, um Ihre Maven-Artefakte zu hosten.
  2. Verwenden Sie das github site-maven-plugin , um Ihre Artefakte in github zu verschieben.
  3. Konfigurieren Sie maven so, dass Ihr entfernter mvn-repo als Maven-Repository verwendet wird.

Die Verwendung dieses Ansatzes hat mehrere Vorteile:

  • Maven-Artefakte werden getrennt von Ihrer Quelle in einem separaten Zweig mit dem Namen mvn-repo abgelegt, ähnlich wie die Github-Seiten in einem separaten Zweig mit dem Namen gh-pages (wenn Sie Github-Seiten verwenden).
  • Im Gegensatz zu anderen Lösungsvorschlägen steht es nicht in Konflikt mit Ihrem gh-pages, wenn Sie diese verwenden.
  • Bindet sich natürlich an das Implementierungsziel, so dass keine neuen Maven-Befehle zu lernen sind. Verwenden Sie einfach mvn deploy wie gewohnt

Die typische Art und Weise, wie Sie Artefakte für ein Remote-Maven-Repo bereitstellen, besteht in mvn deploy. Lassen Sie uns also diesen Mechanismus für diese Lösung verwenden.

Teilen Sie maven zunächst mit, Artefakte an einem temporären Staging-Speicherort in Ihrem Zielverzeichnis bereitzustellen. Fügen Sie dies Ihrem pom.xml hinzu:

<distributionManagement>
    <repository>
        <id>internal.repo</id>
        <name>Temporary Staging Repository</name>
        <url>file://${project.build.directory}/mvn-repo</url>
    </repository>
</distributionManagement>

<plugins>
    <plugin>
        <artifactId>maven-deploy-plugin</artifactId>
        <version>2.8.1</version>
        <configuration>
            <altDeploymentRepository>internal.repo::default::file://${project.build.directory}/mvn-repo</altDeploymentRepository>
        </configuration>
    </plugin>
</plugins>

Versuchen Sie jetzt, mvn clean deploy auszuführen. Sie werden sehen, dass Ihr Maven-Repository auf target/mvn-repo bereitgestellt wurde. Der nächste Schritt besteht darin, dieses Verzeichnis nach GitHub hochzuladen.

Fügen Sie Ihre Authentifizierungsinformationen zu ~/.m2/settings.xml hinzu, damit der github site-maven-plugin Push an GitHub senden kann:

<!-- NOTE: MAKE SURE THAT settings.xml IS NOT WORLD READABLE! -->
<settings>
  <servers>
    <server>
      <id>github</id>
      <username>YOUR-USERNAME</username>
      <password>YOUR-PASSWORD</password>
    </server>
  </servers>
</settings>

(Wie bereits erwähnt, stellen Sie bitte sicher, dass Sie chmod 700 settings.xml eingeben, um sicherzustellen, dass niemand Ihr Kennwort in der Datei lesen kann. Wenn jemand weiß, wie Site-Maven-Plugin aufgefordert wird, ein Kennwort einzugeben, anstatt es in einer Konfigurationsdatei zu benötigen, lassen Sie es mich wissen.)

Dann teilen Sie dem GitHub site-maven-plugin den neuen Server mit, den Sie gerade konfiguriert haben, indem Sie Ihrem Pom Folgendes hinzufügen:

<properties>
    <!-- github server corresponds to entry in ~/.m2/settings.xml -->
    <github.global.server>github</github.global.server>
</properties>

Konfigurieren Sie schließlich den site-maven-plugin, um ihn von Ihrem temporären Staging-Repo in Ihren mvn-repo-Zweig auf Github hochzuladen:

<build>
    <plugins>
        <plugin>
            <groupId>com.github.github</groupId>
            <artifactId>site-maven-plugin</artifactId>
            <version>0.11</version>
            <configuration>
                <message>Maven artifacts for ${project.version}</message>  <!-- git commit message -->
                <noJekyll>true</noJekyll>                                  <!-- disable webpage processing -->
                <outputDirectory>${project.build.directory}/mvn-repo</outputDirectory> <!-- matches distribution management repository url above -->
                <branch>refs/heads/mvn-repo</branch>                       <!-- remote branch name -->
                <includes><include>**/*</include></includes>
                <repositoryName>YOUR-REPOSITORY-NAME</repositoryName>      <!-- github repo name -->
                <repositoryOwner>YOUR-GITHUB-USERNAME</repositoryOwner>    <!-- github username  -->
            </configuration>
            <executions>
              <!-- run site-maven-plugin's 'site' target as part of the build's normal 'deploy' phase -->
              <execution>
                <goals>
                  <goal>site</goal>
                </goals>
                <phase>deploy</phase>
              </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Der mvn-repo-Zweig muss nicht vorhanden sein, er wird für Sie erstellt.

Führen Sie jetzt erneut mvn clean deploy aus. Sie sollten maven-deploy-plugin sehen, wie die Dateien in Ihr lokales Staging-Repository im Zielverzeichnis "hochgeladen" werden. Anschließend wird das site-maven-plugin diese Dateien festschreiben und an den Server senden.

[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building DaoCore 1.3-SNAPSHOT
[INFO] ------------------------------------------------------------------------
...
[INFO] --- maven-deploy-plugin:2.5:deploy (default-deploy) @ greendao ---
Uploaded: file:///Users/mike/Projects/greendao-emmby/DaoCore/target/mvn-repo/com/greendao-orm/greendao/1.3-SNAPSHOT/greendao-1.3-20121223.182256-3.jar (77 KB at 2936.9 KB/sec)
Uploaded: file:///Users/mike/Projects/greendao-emmby/DaoCore/target/mvn-repo/com/greendao-orm/greendao/1.3-SNAPSHOT/greendao-1.3-20121223.182256-3.pom (3 KB at 1402.3 KB/sec)
Uploaded: file:///Users/mike/Projects/greendao-emmby/DaoCore/target/mvn-repo/com/greendao-orm/greendao/1.3-SNAPSHOT/maven-metadata.xml (768 B at 150.0 KB/sec)
Uploaded: file:///Users/mike/Projects/greendao-emmby/DaoCore/target/mvn-repo/com/greendao-orm/greendao/maven-metadata.xml (282 B at 91.8 KB/sec)
[INFO] 
[INFO] --- site-maven-plugin:0.7:site (default) @ greendao ---
[INFO] Creating 24 blobs
[INFO] Creating tree with 25 blob entries
[INFO] Creating commit with SHA-1: 0b8444e487a8acf9caabe7ec18a4e9cff4964809
[INFO] Updating reference refs/heads/mvn-repo from ab7afb9a228bf33d9e04db39d178f96a7a225593 to 0b8444e487a8acf9caabe7ec18a4e9cff4964809
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 8.595s
[INFO] Finished at: Sun Dec 23 11:23:03 MST 2012
[INFO] Final Memory: 9M/81M
[INFO] ------------------------------------------------------------------------

Besuchen Sie github.com in Ihrem Browser, wählen Sie den Zweig mvn-repo aus, und überprüfen Sie, ob alle Ihre Binärdateien jetzt vorhanden sind.

enter image description here

Herzliche Glückwünsche!

Sie können jetzt Ihre Maven-Artefakte für das öffentliche Repo eines armen Mannes bereitstellen, indem Sie einfach mvn clean deploy ausführen.

Es gibt noch einen weiteren Schritt, den Sie machen möchten: Konfigurieren Sie alle Poms, die von Ihrem Pom abhängig sind, um zu wissen, wo sich Ihr Repository befindet. Fügen Sie dem Pom eines Projekts, das von Ihrem Projekt abhängt, den folgenden Ausschnitt hinzu:

<repositories>
    <repository>
        <id>YOUR-PROJECT-NAME-mvn-repo</id>
        <url>https://raw.github.com/YOUR-USERNAME/YOUR-PROJECT-NAME/mvn-repo/</url>
        <snapshots>
            <enabled>true</enabled>
            <updatePolicy>always</updatePolicy>
        </snapshots>
    </repository>
</repositories>

Jetzt werden alle Projekte, für die Ihre JAR-Dateien erforderlich sind, automatisch von Ihrem Github Maven-Repository heruntergeladen.

Bearbeiten: Um das in den Kommentaren erwähnte Problem zu vermeiden ("Fehler beim Erstellen des Commits: Ungültige Anforderung. Für 'Eigenschaften/Name' ist nil keine Zeichenfolge.), Geben Sie in github einen Namen in Ihrem Profil an.

455
emmby

Verwenden Sie GitHub nicht als Maven-Repository.

Bearbeiten: Bei dieser Option werden viele Stimmen abgegeben, jedoch keine Kommentare zu den Gründen. Dies ist die richtige Option, unabhängig von den technischen Möglichkeiten, um tatsächlich auf GitHub zu hosten. Das Hosting auf GitHub ist aus allen unten genannten Gründen falsch. Ohne Kommentare kann ich die Antwort nicht verbessern, um Ihre Probleme zu klären.

Beste Option - Zusammenarbeit mit dem ursprünglichen Projekt

Die beste Option ist, das ursprüngliche Projekt davon zu überzeugen, die Änderungen zu übernehmen und beim Original zu bleiben.

Alternative - Pflegen Sie Ihre eigene Gabel

Da Sie eine Open-Source-Bibliothek gegabelt haben und Ihr Fork ebenfalls Open Source ist, können Sie Ihren Fork nach Maven Central hochladen (read Anleitung zum Hochladen von Artefakten in das zentrale Repository ), indem Sie ihm eine neue groupId und möglicherweise eine neue geben artifactId.

Berücksichtigen Sie diese Option nur, wenn Sie diese Verzweigung beibehalten möchten, bis die Änderungen in das ursprüngliche Projekt übernommen wurden und Sie diese Änderungen dann aufgeben sollten. 

Überlegen Sie wirklich, ob eine Gabel die richtige Option ist. Lesen Sie die unzähligen Google-Ergebnisse für 'Warum nicht Gabelung'

Begründung 

Aufblähen Ihres Repositorys mit Gläsern erhöht die Downloadgröße ohne Nutzen

Ein jar ist eine output Ihres Projekts, es kann jederzeit aus seiner inputs regeneriert werden, und Ihr GitHub-Repo sollte nur inputs enthalten.

Glaub mir nicht Überprüfen Sie dann die Google-Ergebnisse auf 'dont store binaries in git'

GitHub's Hilfe Arbeiten mit großen Dateien wird Ihnen dasselbe sagen. Zugegebenermaßen sind Gläser nicht groß, aber sie sind größer als der Quellcode, und sobald ein Behälter durch ein Release erstellt wurde, haben sie keinen Grund zur Versionierung - dafür gibt es ein neues Release.

Das Definieren mehrerer Repos in Ihrer pom.xml-Datei verlangsamt den Aufbau um die Anzahl der Repositorys und die Anzahl der Artefakte.

Stephen Connolly sagt

Wenn jemand Ihr Repo hinzufügt, wirkt sich dies auf die Build-Leistung aus Da sie jetzt ein weiteres Repo haben, um Artefakte gegen ... zu prüfen, ist das kein großer Problem, wenn Sie nur ein Repo hinzufügen müssen ... Aber das Problem wird größer und das nächste Sie wissen, dass Ihr Maven Build 50 Repos für jedes Artefakt und .__ prüft. Bauzeit ist ein Hund.

Stimmt! Maven muss jedes in Ihrer pom.xml definierte Artefakt (und seine Abhängigkeiten) mit jedem von Ihnen definierten Repository prüfen., Da in diesen Repositorys möglicherweise eine neuere Version verfügbar ist. 

Probieren Sie es aus und Sie werden den Schmerz eines langsamen Builds spüren. 

Der beste Ort für Artefakte ist in Maven Central, dem zentralen Ort für Gläser. Dies bedeutet, dass Ihr Build immer nur one place überprüft.

Weitere Informationen zu Repositories finden Sie in der Dokumentation von Maven unter Einführung in Repositories

112
Bae

Sie können JitPack (kostenlos für öffentliche Git-Repositorys) verwenden, um Ihr GitHub-Repository als Maven-Artefakt verfügbar zu machen. Es ist sehr leicht. Ihre Benutzer müssten dies zu ihrer pom.xml hinzufügen: 

  1. Repository hinzufügen:
<repository>
    <id>jitpack.io</id>
    <url>https://jitpack.io</url>
</repository>
  1. Abhängigkeit hinzufügen:
<dependency>
    <groupId>com.github.User</groupId>
    <artifactId>Repo name</artifactId>
    <version>Release tag</version>
</dependency>

Wie beantwortet anderswo Die Idee ist, dass JitPack Ihr GitHub-Repo erstellt und die Gläser liefert. Voraussetzung ist, dass Sie eine Build-Datei und eine GitHub-Version haben.

Das Schöne daran ist, dass Sie nicht mit der Bereitstellung und den Uploads fertig werden müssen. Da Sie kein eigenes Artefakt-Repository unterhalten möchten, ist es eine gute Wahl für Ihre Anforderungen.

40
Andrejs

Eine andere Alternative ist die Verwendung eines beliebigen Webhosting mit Unterstützung für Webdav. Sie benötigen natürlich etwas Platz dafür, aber es ist einfach einzurichten und eine gute Alternative zum Ausführen eines voll ausgebauten Nexus-Servers.

fügen Sie dies Ihrem Build-Abschnitt hinzu

     <extensions>
        <extension>
        <artifactId>wagon-webdav-jackrabbit</artifactId>
        <groupId>org.Apache.maven.wagon</groupId>
        <version>2.2</version>
        </extension>
    </extensions>

Fügen Sie so etwas zu Ihrem Verteilungsmanagementbereich hinzu

<repository>
    <id>release.repo</id>
    <url>dav:http://repo.jillesvangurp.com/releases/</url>
</repository>

Stellen Sie schließlich sicher, dass Sie den Repository-Zugriff in Ihrer Einstellungen.xml einrichten

fügen Sie dies Ihrem Server-Abschnitt hinzu

    <server>
        <id>release.repo</id>
        <username>xxxx</username>
        <password>xxxx</password>
    </server>

und eine Definition für Ihren Repository-Abschnitt

            <repository>
                <id>release.repo</id>
                <url>http://repo.jillesvangurp.com/releases</url>
                <releases>
                    <enabled>true</enabled>
                </releases>
                <snapshots>
                    <enabled>false</enabled>
                </snapshots>
            </repository>

Wenn Sie über ein Standard-PHP-Hosting verfügen, können Sie mit sabredav Webdav-Funktionen hinzufügen.

Vorteile: Sie haben Ihr eigenes Maven-Repository Nachteile: Sie verfügen nicht über die Verwaltungsfunktionen in nexus. Sie brauchen irgendwo ein Webdav-Setup

8
Jilles van Gurp

Als Alternative bietet Bintray das kostenlose Hosting von Maven-Repositories an. Das ist wahrscheinlich eine gute Alternative zu Sonatype OSS und Maven Central, wenn Sie die groupId nicht unbedingt umbenennen möchten. Aber bitte, bemühen Sie sich zumindest, Ihre Änderungen in den Upstream zu integrieren oder umzubenennen und in Central zu veröffentlichen. Es erleichtert anderen die Verwendung Ihrer Gabel.

7
Guillaume

Wenn Sie nur eine aar- oder jar-Datei haben oder einfach keine Plugins verwenden möchten, habe ich ein einfaches Shell-Skript erstellt. Sie können dasselbe erreichen, indem Sie Ihre Artefakte in Github veröffentlichen und als öffentliches Maven-Repo verwenden. 

0
Orest Savchak