Hébergement d'un référentiel Maven sur github

J'ai un fork d'une petite bibliothèque open source sur laquelle je travaille sur github. Je voudrais le rendre disponible à d'autres développeurs via maven, mais je ne veux pas exécuter mon propre serveur Nexus, et parce que c'est un fork, je ne peux pas facilement le déployer sur oss.sonatype.org.

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

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

1. Créez une branche appelée mvn-repopour héberger vos artefacts maven.
2. Utilisez le plugin github site-maven pour pousser vos artefacts vers github.
3. Configurez maven pour utiliser votre télécommande mvn-repocomme 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 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-pagessi vous les utilisez.
• S'associe naturellement à la cible de déploiement, il n'y a donc pas de nouvelles commandes maven à apprendre. Utilisez simplement mvn deploycomme vous le feriez normalement

La façon typique de déployer des artefacts sur un référentiel maven distant est d'utiliser mvn deploy, nous allons donc patcher dans ce mécanisme pour cette solution.

Tout d'abord, dites à maven de déployer les 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 courir mvn clean deploy. Vous verrez qu'il a déployé votre référentiel maven surtarget/mvn-repo . L'étape suivante consiste à obtenir qu'il télécharge ce répertoire sur GitHub.

Ajoutez vos informations d'authentification ~/.m2/settings.xmlpour que le github site-maven-pluginpuisse pousser vers 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é, assurez-vous de chmod 700 settings.xml assurer que personne ne peut lire votre mot de passe dans le fichier. Si quelqu'un sait comment demander au site-maven-plugin un mot de passe au lieu de l'exiger dans un fichier de configuration, faites-le moi savoir.)

Ensuite, informez le GitHub site-maven-plugindu 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-plugintéléchargement de votre référentiel temporaire vers votre mvn-reposuccursale 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>

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

Maintenant, exécutez à mvn clean deploynouveau. Vous devriez voir maven-deploy-plugin "télécharger" les fichiers vers votre référentiel de stockage 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] ------------------------------------------------------------------------

Visitez github.com dans votre navigateur, sélectionnez la mvn-reposuccursale et vérifiez que tous vos fichiers binaires sont maintenant là.

Toutes nos félicitations!

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

Il y a une autre étape que vous voudrez prendre, qui est de configurer tous les poms qui dépendent de votre pom pour savoir où se trouve votre référentiel. Ajoutez l'extrait suivant au pom de tout projet qui dépend de votre projet:

<repositories>
    <repository>
        <id>YOUR-PROJECT-NAME-mvn-repo</id>
        <url>https://github.com/YOUR-USERNAME/YOUR-PROJECT-NAME/raw/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 depuis votre référentiel github maven.

Edit: pour éviter le problème mentionné dans les commentaires ('Erreur lors de la création du commit: requête non valide. Pour' propriétés / nom ', nil n'est pas une chaîne.'), Assurez-vous d'indiquer un nom dans votre profil sur github.

N'utilisez pas GitHub comme référentiel Maven.

Edit: Cette option obtient beaucoup de votes négatifs, mais aucun commentaire sur la raison. C'est l'option correcte quelles que soient les capacités techniques à héberger sur GitHub. L'hébergement sur GitHub est mauvais 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 - Collaborez avec le projet d'origine

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

Alternative - Entretenez votre propre fourche

Comme vous avez créé une bibliothèque open source et que votre fork est également open source, vous pouvez télécharger votre fork sur Maven Central (lire le Guide de téléchargement d'artefacts dans le référentiel central ) en lui donnant un nouveaugroupId et peut-être un nouveau artifactId.

Ne considérez cette option que si vous êtes prêt à conserver cette fourchette jusqu'à ce que les modifications soient incorporées dans le projet d'origine, puis vous devez abandonner celui-ci.

Réfléchissez vraiment si une fourche est la bonne option. Lisez la myriade de résultats Google pour «pourquoi ne pas bifurquer»

Raisonnement

Faire gonfler votre référentiel avec des pots augmente la taille du téléchargement sans aucun avantage

Un bocal fait partie outputde votre projet, il peut être régénéré à tout moment à partir de son inputs, et votre dépôt GitHub ne doit contenir que inputs.

Tu ne me crois pas? Vérifiez ensuite les résultats de Google pour «ne pas stocker les binaires dans git» .

L'aide de GitHub Travailler avec des fichiers volumineux vous dira la même chose. Certes, les fichiers jar ne sont pas grands, mais ils sont plus grands que le code source et une fois qu'un fichier a été créé par une version, ils n'ont aucune raison d'être versionnés - c'est à cela que sert une nouvelle version.

La définition de plusieurs référentiels dans votre pom.xml ralentit votre génération par le nombre de référentiels multiplié par le nombre d'artefacts

Stephen Connolly dit :

Si quelqu'un ajoute votre dépôt, il a un impact sur ses performances de construction, car il a maintenant un autre dépôt pour vérifier les artefacts ... Ce n'est pas un gros problème si vous n'avez qu'à ajouter un dépôt ... Mais le problème augmente et la prochaine chose que vous connaissez votre maven build vérifie 50 dépôts pour chaque artefact et le temps de construction 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 peut être disponible dans l'un de ces référentiels.

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

Le meilleur endroit pour les artefacts est dans Maven Central, car c'est l'endroit central pour les bocaux, et cela signifie que votre construction ne vérifiera qu'un seul endroit.

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

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

1. Ajouter un référentiel:

<repository>
    <id>jitpack.io</id>
    <url>https://jitpack.io</url>
</repository>

2. Ajouter une dépendance:

<dependency>
    <groupId>com.github.User</groupId>
    <artifactId>Repo name</artifactId>
    <version>Release tag</version>
</dependency>

Comme indiqué 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 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 vouliez pas maintenir votre propre référentiel d'artefacts, il correspond bien à vos besoins.

Une autre alternative consiste à utiliser n'importe quel hébergement web avec support webdav. Vous aurez besoin d'un peu d'espace pour cela quelque part, bien sûr, mais il est simple à configurer et 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 ça à votre section de gestion de distribution

<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 settings.xml

ajoutez ceci à votre section serveurs

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

et une définition à 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 capacités webdav.

Avantages: vous avez votre propre référentiel maven Inconvénients: vous n'avez aucune des capacités de gestion dans nexus; vous avez besoin d'une configuration webdav quelque part

Depuis 2019, vous pouvez désormais utiliser la nouvelle fonctionnalité appelée registre de packages Github .

Fondamentalement, le processus est le suivant:

• générer un nouveau jeton d'accès personnel à partir des paramètres github
• ajouter des informations de référentiel et de jeton dans votre settings.xml

• déployer à l'aide

  mvn deploy -Dregistry=https://maven.pkg.github.com/yourusername -Dtoken=yor_token  

Comme alternative, Bintray fournit un hébergement gratuit des référentiels maven. C'est probablement une bonne alternative à Sonatype OSS et Maven Central si vous ne voulez absolument pas renommer le groupId. Mais s'il vous plaît, faites au moins un effort pour intégrer vos modifications en amont ou renommer et publier sur Central. Cela rend beaucoup plus facile pour les autres d'utiliser votre fourche.

Si vous avez seulement aarou jarfichier lui - même, ou tout simplement ne voulez pas utiliser des plugins - j'ai créé un script shell simple . Vous pouvez obtenir le même résultat en publiant vos artefacts sur Github et en l'utilisant comme référentiel public Maven.