web-dev-qa-db-fra.com

Hébergement d'un dépôt Maven sur github

J'ai une fourchette d'une petite bibliothèque ouverte sur laquelle je travaille sur github. J'aimerais pouvoir le mettre à la disposition des autres développeurs via maven, mais je ne veux pas utiliser mon propre serveur Nexus, et comme c'est un fork, je ne peux pas le déployer facilement sur oss.sonatype.org.

Ce que j'aimerais faire, c'est le déployer sur github afin que d'autres puissent y accéder en utilisant maven. Quelle est la meilleure façon de faire cela?

mavengithubgithub-pagesmvn-repo
291
emmby

La meilleure solution que j'ai pu trouver consiste en ces étapes:

  1. Créez une branche appelée mvn-repo pour héberger vos artefacts Maven.
  2. Utilisez github site-maven-plugin pour pousser vos artefacts vers github.
  3. Configurez maven pour utiliser votre mvn-repo distant en tant que référentiel maven.

Cette approche présente plusieurs avantages:

  • Les artefacts Maven sont conservés séparément de votre source dans une branche distincte appelée mvn-repo, tout comme les pages de github sont conservées dans une branche distincte appelée gh-pages (si vous utilisez des pages github).
  • Contrairement à d'autres solutions proposées, cela n'entre pas en conflit avec votre gh-pages si vous les utilisez.
  • S'intègre naturellement à la cible de déploiement pour qu'il n'y ait aucune nouvelle commande maven à apprendre. Utilisez simplement mvn deploy comme vous le feriez normalement

La manière habituelle de déployer des artefacts sur un dépôt Maven distant consiste à utiliser mvn deploy, aussi modifions-nous dans ce mécanisme pour cette solution.

Commencez par indiquer à maven de déployer des artefacts dans un emplacement de stockage temporaire dans votre répertoire cible. Ajoutez ceci à votre pom.xml:

<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>

Maintenant, essayez de lancer mvn clean deploy. Vous verrez qu'il a déployé votre référentiel Maven sur target/mvn-repo. La prochaine étape consiste à le faire télécharger ce répertoire sur GitHub.

Ajoutez vos informations d'authentification à ~/.m2/settings.xml pour que le github site-maven-plugin puisse envoyer à GitHub:

<!-- 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>

(Comme indiqué, veuillez vous assurer que chmod 700 settings.xml s'assure que personne ne peut lire votre mot de passe dans le fichier. Si quelqu'un sait comment faire site-maven-plugin Demander un mot de passe au lieu de l'exiger dans un fichier de configuration, faites le moi savoir.)

Dites ensuite à GitHub site-maven-plugin le nouveau serveur que vous venez de configurer en ajoutant ce qui suit à votre pom:

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

Enfin, configurez le site-maven-plugin pour le télécharger depuis votre référentiel intermédiaire temporaire vers votre branche mvn-repo sur Github:

<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>

La branche mvn-repo n'a pas besoin d'exister, elle sera créée pour vous.

Maintenant, exécutez à nouveau mvn clean deploy. Vous devriez voir maven-deploy-plugin "télécharger" les fichiers dans votre référentiel de transfert local dans le répertoire cible, puis site-maven-plugin valider ces fichiers et les envoyer au serveur.

[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] ------------------------------------------------------------------------

Rendez-vous sur github.com dans votre navigateur, sélectionnez la branche mvn-repo et vérifiez que tous vos fichiers binaires y sont maintenant.

enter image description here

Toutes nos félicitations!

Vous pouvez maintenant déployer vos artefacts maven sur le dépôt public d'un homme pauvre en exécutant simplement mvn clean deploy.

Il vous reste une étape à franchir, à savoir configurer tous les poms qui dépendent de votre pom pour savoir où se trouve votre référentiel. Ajoutez l'extrait suivant à tout pom de projet qui dépend de votre projet:

<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>

Désormais, tout projet nécessitant vos fichiers jar les téléchargera automatiquement à partir de votre référentiel github maven.

Éditer: pour éviter le problème mentionné dans les commentaires ('Erreur lors de la création de la validation: demande non valide. Pour' propriétés/nom ', nil n'est pas une chaîne.'), Assurez-vous que vous indiquez un nom dans votre profil sur github.

455
emmby

N'utilisez pas GitHub en tant que référentiel Maven.

Edit: Cette option génère beaucoup de votes négatifs, mais nous ne faisons pas de commentaire. C’est la bonne option, quelles que soient les capacités techniques permettant d’héberger sur GitHub. Héberger sur GitHub est inacceptable pour toutes les raisons décrites ci-dessous et sans. commentaires Je ne peux pas améliorer la réponse pour clarifier vos problèmes.

Meilleure option - Collaborer avec le projet d'origine

La meilleure option consiste à convaincre le projet d'origine d'inclure vos modifications et de vous en tenir à l'original.

Alternative - Conservez votre propre fourchette

Comme vous avez créé une bibliothèque open source et que votre source est également une source ouverte, vous pouvez télécharger votre source dans Maven Central (lire Guide pour le téléchargement d'artefacts dans le référentiel central ) en lui attribuant une nouvelle variable groupId et éventuellement une nouvelle. artifactId.

Ne considérez cette option que si vous souhaitez conserver cette branche jusqu'à ce que les modifications soient intégrées au projet d'origine. Vous devez ensuite abandonner celui-ci. 

Voyez vraiment si une fourchette est la bonne option. Consultez la myriade de résultats Google pour 'pourquoi pas to fork'

Raisonnement 

Gonfler votre référentiel avec des bocaux augmente la taille du téléchargement sans aucun avantage

Un fichier jar est une output de votre projet, il peut être régénéré à tout moment à partir de sa inputs et votre rapport GitHub ne devrait contenir que inputs.

Ne me crois pas? Consultez ensuite les résultats de Google pour "Ne stockez pas les fichiers binaires dans git" . 

Aide de GitHub Travailler avec de gros fichiers vous dira la même chose. Certes, les fichiers jar ne sont pas volumineux, mais ils sont plus volumineux que le code source. Une fois qu'un fichier jar a été créé par une version, il n’ya aucune raison de le modifier. C'est à quoi sert une nouvelle version.

La définition de plusieurs dépôts dans votre pom.xml ralentit votre construction par le nombre de dépôts multiplié par le nombre d'artefacts

Stephen Connolly dit : 

Si quelqu'un ajoute votre rapport, il affecte leur performance de construction comme ils ont maintenant un autre dépôt pour vérifier les artefacts contre ... Ce n'est pas un gros problème si vous devez seulement ajouter un repo ... Mais le problème s'aggrave et le suivant Ce que vous savez que votre maven build vérifie 50 pensions pour chaque artefact et construire le temps est un chien.

C'est vrai! Maven doit vérifier chaque artefact (et ses dépendances) défini dans votre pom.xml par rapport à chaque référentiel que vous avez défini, car une version plus récente pourrait être disponible dans l'un de ces référentiels. 

Essayez par vous-même et vous ressentirez la douleur d'une construction lente. 

Le meilleur endroit pour les artefacts se trouve dans Maven Central, car c'est l'endroit idéal pour les pots, ce qui signifie que votre construction ne vérifiera jamais que un endroit.

Vous pouvez en savoir plus sur les référentiels dans la documentation de Maven sur Introduction aux référentiels

112
Bae

Vous pouvez utiliser JitPack (gratuit pour les référentiels Git publics) pour exposer votre référentiel GitHub en tant qu’artefact Maven. C'est très facile. Vos utilisateurs devront ajouter ceci à leur pom.xml: 

  1. Ajouter un référentiel:
<repository>
    <id>jitpack.io</id>
    <url>https://jitpack.io</url>
</repository>
  1. Ajouter une dépendance:
<dependency>
    <groupId>com.github.User</groupId>
    <artifactId>Repo name</artifactId>
    <version>Release tag</version>
</dependency>

Comme répondu ailleurs l’idée est que JitPack construira votre dépôt GitHub et servira les pots. La condition est que vous ayez un fichier de construction et une version de GitHub.

La bonne chose est que vous n'avez pas à gérer le déploiement et les téléchargements. Étant donné que vous ne voulez pas gérer votre propre référentiel d'artefacts, il correspond parfaitement à vos besoins.

40
Andrejs

Une autre alternative consiste à utiliser n'importe quel hébergement Web avec le support webdav. Vous aurez besoin d’un peu d’espace pour cela quelque part, bien sûr, mais son installation est simple et constitue une bonne alternative à l’exécution d’un serveur Nexus complet.

ajoutez ceci à votre section de construction

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

Ajoutez quelque chose comme ceci à votre section distributionManagement

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

Enfin, assurez-vous de configurer l’accès au référentiel dans votre fichier settings.xml.

ajoutez ceci à la section de vos serveurs

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

et une définition de votre section de référentiels

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

Enfin, si vous avez un hébergement php standard, vous pouvez utiliser quelque chose comme sabredav pour ajouter des fonctionnalités webdav.

Avantages: vous avez votre propre référentiel Maven Inconvénients: vous ne possédez aucune des capacités de gestion de Nexus; vous avez besoin d'une configuration webdav quelque part

8
Jilles van Gurp

Au lieu de cela, Bintray fournit gratuitement l'hébergement de référentiels maven. C'est probablement une bonne alternative à Sonatype OSS et à Maven Central si vous ne voulez absolument pas renommer l'ID de groupe. Mais s'il vous plaît, faites au moins un effort pour intégrer vos modifications en amont ou renommez-les et publiez-les dans Central. Il est beaucoup plus facile pour les autres d’utiliser votre fourchette.

7
Guillaume

Si vous avez uniquement le fichier aar ou jar lui-même, ou si vous ne voulez tout simplement pas utiliser de plug-ins - j'ai créé un simple script shell . Vous pouvez obtenir le même résultat: publier vos artefacts sur Github et les utiliser en tant que dépôt Maven public. 

0
Orest Savchak