L'hébergement d'un Maven repository sur github

J'ai une fourche d'un petit open source de la bibliothèque que je suis en train de travailler sur github. J'aimerais le rendre disponible à d'autres développeurs via maven, mais je ne veux pas lancer mon propre serveur Nexus, et parce que c'est une fourchette, je ne peux pas facilement mettre à oss.sonatype.org.

Ce que je voudrais faire est de déployer sur github afin que d'autres puissent accéder à l'aide de maven. Quelle est la meilleure façon de le faire?

InformationsquelleAutor emmby | 2012-12-23
  1. 466

    La meilleure solution que j'ai pu trouver se compose des étapes suivantes:

    1. Créer une branche appelée mvn-repo pour accueillir vos artefacts maven.
    2. Utiliser le github site-maven-plugin pour pousser vos objets de github.
    3. Configurer maven pour utiliser votre télécommande mvn-repo comme un référentiel.

    Il y a plusieurs avantages à l'utilisation de cette approche:

    • Maven artefacts sont séparés à partir de votre source dans une branche séparée appelée mvn-repo, un peu comme github pages sont conservées dans une branche distincte appelée gh-pages (si vous utilisez github pages)
    • Contrairement à certains autres solutions proposées, il n'entre pas en conflit avec votre gh-pages si vous les utilisez.
    • Liens naturellement avec le déploiement de la cible, donc il n'y a pas de nouvelles commandes maven à apprendre. Utilisez simplement mvn deploy comme vous le feriez normalement

    Typique de la façon de déployer des artefacts à une distance repo maven est d'utiliser mvn deploy, alors allons-patch pour que le mécanisme de cette solution.

    Tout d'abord, dites maven pour déployer des artefacts à un transfert temporaire de l'emplacement à l'intérieur de 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 d'exécuter mvn clean deploy. Vous verrez que il a déployé votre repository maven pour target/mvn-repo. La prochaine étape consiste à obtenir pour télécharger ce répertoire GitHub.

    Ajouter vos informations d'authentification pour ~/.m2/settings.xml de sorte que le github site-maven-plugin pouvez pousser 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 l'a noté, assurez-vous de chmod 700 settings.xml pour s'assurer 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 config, laissez-moi savoir.)

    Alors dites-le GitHub site-maven-plugin sur le nouveau serveur que vous venez de configurer en ajoutant les lignes suivantes à 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 à télécharger à partir de votre transit temporaire des pensions de votre mvn-repo branche 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 mvn-repo branche n'a pas besoin d'exister, il sera créé pour vous.

    Maintenant exécuter mvn clean deploy de nouveau. Vous devriez voir maven-déployer-plugin "upload" les fichiers de votre local, mise en scène de référentiel dans le répertoire cible, puis site-maven-plugin de commettre ces fichiers et de les pousser vers le 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] ------------------------------------------------------------------------

    Visite github.com dans votre navigateur, sélectionnez le mvn-repo de la branche, et de vérifier que tous vos fichiers binaires sont maintenant là.

    L'hébergement d'un Maven repository sur github

    Félicitations!

    Vous pouvez maintenant déployer votre maven objets à un pauvre homme public des pensions de simplement en exécutant mvn clean deploy.

    Il y a une étape de plus vous aurez envie de prendre, qui est de configurer tous les boutons qui dépendent de votre pom de savoir où votre dépôt. Ajouter l'extrait de code suivant à tout pom du 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>

    Maintenant tout projet qui a besoin de vos fichiers jar télécharger automatiquement à partir de votre github repository maven.

    Edit: pour éviter le problème mentionné dans les commentaires ("Erreur de création de commettre: demande non Valide. Pour les "propriétés/nom', nil n'est pas une chaîne de caractères.'), assurez-vous de l'état un nom dans votre profil sur github.

    • (À noter que la meilleure façon d'hôte artefacts maven est de toujours utiliser un serveur nexus. Cependant, l'utilisation de github peut fonctionner comme une alternative légère quand un serveur existant ou de l'hébergement de votre propre n'est pas une option facile. Notez également que vous ne serez pas en mesure de naviguer dans votre repository maven directement. Github ne vous autorise pas à parcourir l'annuaire des structures lors de l'utilisation des matières premières. Cependant, vous pouvez toujours parcourir le repo en allant sur votre page github et de la navigation sur le mvn-repo branche.)
    • Notez également que cette solution permettra de remplacer votre antérieur artefacts chaque fois que vous déployez. Ceci est approprié pour l'instantané référentiels, mais pas pour une mise à disposition des artefacts. Pour désactiver ce comportement, ensemble <merge>true</merge> dans votre site-maven-plugin de configuration. Si vous le faites, cependant, je pense que vous allez avoir à créer manuellement le mvn-repo branche sur github et supprimer tous les fichiers de la première fois autour.
    • +1 astucieux et très bien présenté. Ma seule critique est que vous n'avez pas d'inclure un lien vers les plugins Maven site: github.com/github/maven-plugins. Thx, je cherchais un moyen de publier mon Maven site de github!
    • Approche Alternative qui peut-être prend soin de votre problème de contrôle de version: cemerick.com/2010/08/24/hosting-maven-repos-on-github. Moins élégant, mais utilise Maven client de publier localement. On pourrait peut-être encorporate ce dans un nouveau plugin Maven pour git.
    • Merci Marc! Merci pour le lien. Je n'ai fait d'inclure un lien vers github.com/github/maven-plugins#readme, mais il est utile de l'avoir ici. Aussi, le cemerick lien a été un point de départ pour cette solution. C'est bien tout ça, mais il n'a pas d'automatiser le pousser à github.
    • Je reprends ma critique 🙂
    • Cet ingénieux hack semble fonctionner si vous êtes propriétaire de la source à l'jar que vous souhaitez publier, mais que faire si vous n'avez pas la source?
    • Merci pour ce peu de fraîcheur approche @emmby. Mais comme il est mentionné dans le ci-dessous post, pourriez-vous préciser un peu comme à la manière dont un autre POM du projet serait de référence les binaires que nous pousser à notre repo...? Surtout, qu'est-ce qui n'en <id> & <url> éléments du référentiel? Est-il de la convention de là..? Peut-on tester l'url pour vous assurer qu'il fonctionne bien...? J'ai été en mesure de créer des & pousser le mvn-pensions de branche pour mon projet sur GitHub. Mais pas clair comment spécifier le repo URL & id dans le projet dépendant de la POM. (Veuillez vous référer à mon post ci-dessous). Merci beaucoup.
    • Si j'ai spécifié le nom d'utilisateur et mot de passe dans la settings.xml tout en utilisant github comme référentiel le build n'est pas en mesure de télécharger les fichiers. <repositories> <repository> <id>id</id> <url>https://github.com/My-Group/comapny/tree/mvn-repo/</url> <snapshots> <enabled>true</enabled> <updatePolicy>always</updatePolicy> </snapshots> </repository> </repositories>
    • fait quelques modifications qui sont complètement éclaté de cela pour moi. Plus précisément le distributionManagement section cessé de travailler. Je suis revenue à la version précédente, mais voir stackoverflow.com/revisions/14013645/3 si vous voulez voir ses révisions
    • Cette approche ne fonctionne pas lorsque l'authentification à Deux facteurs est utilisé sur github. Voir ma note dans le problème ici: github.com/github/maven-plugins/issues/36#issuecomment-31005606
    • Afin de faire ce travail pour multi-projets de module, vous pouvez aussi simplement utiliser des <altDeploymentRepository>internal.repo::default::file://${user.dir}/target/mvn-repo</altDeploymentRepository> avec le maven-déployer-plugin, et <outputDirectory>${user.dir}/target/mvn-repo</outputDirectory> avec site-maven-plugin. Cela permettra de déployer tous les artefacts dans la racine ("parent") du projet, et de la pousser à la parents respectifs direcory sur github. Sinon, la construction de chaque sous-module de réécriture que de le sous-module construit avant...
    • Dans les paramètres du serveur, vous pouvez omettre votre nom d'utilisateur et remplacer votre mot de passe avec une portée limitée dans le jeton d'accès. Voir: github.com/github/maven-plugins
    • Si vous ne voulez pas inclure votre login dans votre github settings.xml vous pouvez utiliser OAuth2
    • Si vous utilisez maven version 3.1 ou supérieur, vous avez besoin de changer la version de site-maven-plugin à 0,9, ou vous allez voir cette erreur: Exécution par défaut de l'objectif com.github.github:site-maven-plugin:0.8:site a échoué: Une API incompatibilité a été rencontrées pendant l'exécution de com.github.github:site-maven-plugin:0.8:site: java.lang.NoSuchMethodError: org.apache.maven.execution.MavenSession.getRepositorySession()Lorg/sonatype/aether/RepositorySystemSession;
    • Merci pour la réponse impressionnante. J'avais réussi à l'hôte maven repo github. Comment puis-je obtenir ce pour bitbucket.
    • merveilleux de réponse... le tout fonctionne comme un charme.. la seule chose que je suis encore à comprendre, c'est comment faire si mon repo git est privé... toute aide?
    • Cela ne semble pas fonctionner avec l'état actuel de github
    • Deux suggestions que faire fonctionner (au moins pour moi): Jeu version actuelle de Github plugin (à droite maintenant, il serait 0.11). Aussi je suggère à tout le monde d'utiliser un jeton OAUTH au lieu du mot de passe. Vous pouvez la générer dans Settings->Applications->Accès Personnel Jetons". Que vous pouvez inclure dans le POM via et de stocker le jeton comme une variable d'environnement. <github.global.userName>YourUserName</github.global.userName> <github.global.password>${GITHUB_OAUTH_TOKEN</github.global.password>
    • Cette réponse sonne comme une surcharge par rapport à ce que Bae propose dans sa réponse...
    • j'ai essayé votre solution, et le maven-site-plugin dit: basedir n'existe pas (malgré le fait que c'est en effet en existe un). 🙁
    • Est-il un moyen de l'utiliser avec une organisation repo? J'ai essayé d'utiliser le nom de l'organisation dans le <repositoryName> élément, mais il ne fonctionne pas. J'ai aussi essayé avec l'organisation propriétaire des noms d'utilisateur pour le même résultat.
    • Il est possible de l'utiliser avec une organisation repo. Utilisez votre github nom d'utilisateur et mot de passe dans la settings.xml fichier et mettre en <repositoryOwner>your-organization-name</repositoryOwner> dans le fichier pom.
    • Salut, suite au-dessus de la suggestion, je suis en dessous de trace de l'erreur tout en faisant mvn deploy. org.apache.maven.cycle de vie.LifecycleExecutionException: Échec de l'exécution de l'objectif com.github.github:site-maven-plugin:0.12:site (par défaut) sur project spark-parent_2.10: Erreur lors de la création de commettre: demande non Valide. Pour les "propriétés/nom', nil n'est pas une chaîne. Pour les "propriétés/nom', nil n'est pas une chaîne.
    • Merci! son travail..
    • J'ai une vidéo de tutoriel sur Maven déployer (youtube.com/watch?v=gBd5Yraoqp4) et la libération (youtube.com/watch?v=FFq0V_LZGZ4) pour GitHub.
    • Cette méthode implique une mise en pension par artefact approche. Bien sûr, vous pouvez utiliser le même partagé répertoire de transit pour tous les artefacts, mais une fois que vous avez une assez grande repo vous avez des problèmes avec Java segment de mémoire. Je préfère utiliser le Maven plugin exec et appelez le git binaire de pousser les nouveaux artefacts.
    • Quelqu'un a eu à travailler avec des dépôts privés en décembre 2016? Peut-être redondant, mais j'ai posé la question ici: stackoverflow.com/questions/41192900/.... Le projet dépendant n'a pas pu télécharger le pot en utilisant soit le nom d'utilisateur et le mot de passe, ou d'un jeton, lorsque l'opération a été privé. Les choses étaient très bien quand il était public.
    • ce qui s'est passé pour moi quand j'ai copier coller le code ci-dessus. Il a fait quelque chose d'étrange avec le codage de caractères du nom de fichier. Essayez de taper mvn-repo explicitement, cela devrait fonctionner.
    • Merci pour ce post, il est très utile. Cependant, après tout, travailler sur un multi-projet de module, j'ai trouvé qu'il y a quelques GitHub restrictions sur la taille des objets. Nous avons quelques all-inclusive uber-pots qui étaient de 50 mo, et le télécharger sur GitHub a échoué pour ceux (je suppose à cause de leur taille, les plus petits ont travaillé). Il a également été très lente à charger. Je pense à un privé résultant de pensions ou de l'un de ces services est vraiment la seule façon d'aller pour un important projet.
    • Il m'a fallu quelques tentatives pour obtenir des choses de travail avec un github personne jeton d'accès. ici c'est un exemple dans le domaine public github.com/simbo1905/microservices-demo/blob/... Vous avez besoin de générer un GitHub personnels jeton d'accès et de lui donner la portée de publier à la mise en pension et de lire votre adresse e-mail que par github.com/github/maven-plugins/issues/.... Ensuite, vous devez définir le jeton comme un envar avec export GITHUB_OAUTH_TOKEN=xxx

    InformationsquelleAutor emmby
  2. 116

    Ne pas utiliser GitHub comme un Référentiel.

    Edit: Cette option obtient beaucoup de votes contre, mais pas de commentaires quant à savoir pourquoi. C'est l'option correcte quelle que soit la technique, les capacités à accueillir sur GitHub. L'hébergement sur GitHub est pas le cas pour toutes les raisons exposées ci-dessous et sans commentaires, je ne peux pas améliorer la réponse à clarifier vos questions.

    Meilleure Option - Collaborer avec le Projet d'Origine

    La meilleure option est de les convaincre que le projet original d'inclure vos modifications et le bâton avec l'original.

    Alternative, de Maintenir votre Fourchette

    Puisque vous avez fourchue, une bibliothèque open source, et votre fourche est également open source, vous pouvez télécharger votre fourche à Maven Central (lire Guide pour le téléchargement des artefacts vers le Dépôt Central) en lui donnant une nouvelle groupId et peut-être une nouvelle artifactId.

    Seulement envisager cette option si vous êtes prêt à maintenir cette fourchette jusqu'à ce que les modifications sont intégrées dans le projet d'origine, alors vous devriez abandonner celui-ci.

    Examiner vraiment dur de savoir si une fourche, c'est la bonne option. Lire la myriade de résultats de Google pour "pourquoi pas à la fourche"

    Raisonnement

    Ballonnements votre référentiel avec des bocaux augmente la taille de téléchargement pour aucun avantage

    Un pot est un output de votre projet, il peut être régénéré à tout moment à partir de son inputs, et votre dépôt GitHub doit contenir uniquement inputs.

    Ne me croyez pas? Puis vérifier les résultats de Google pour 'ne pas stocker de fichiers binaires dans git.

    De GitHub aider à Travailler avec des fichiers volumineux vous diront la même chose. Certes jar ne sont pas grandes, mais elles sont plus grandes que le code source et une fois un pot a été créé par une version, ils n'ont aucune raison d'être versionné - qu'est ce qu'une nouvelle version est pour.

    Définition de plusieurs pensions de titres dans votre pom.xml ralentit votre construction par le Nombre de Dépôts de fois Nombre d'Artefacts

    Stephen Connolly dit:

    Si quelqu'un ajoute à votre repo-ils un impact sur leur génération de performance
    maintenant qu'ils ont un autre repo pour vérifier les artefacts contre... C'est pas un gros
    problème si vous n'avez qu'à ajouter un repo... Mais le problème prend de l'ampleur et à la prochaine
    chose que vous savez que votre maven build est la vérification de 50 repos pour chaque artefact et
    le temps de construction est un chien.

    C'est le droit! Maven doit vérifier chaque artefact (et ses dépendances) définis dans votre pom.xml contre chaque Dépôt que vous avez défini, comme une version plus récente pourrait être disponible dans l'un de ces référentiels.

    L'essayer pour vous-même et vous vous sentirez la douleur d'une construction lente.

    Le meilleur endroit pour les objets, est dans Maven Central, comme la place centrale pour les pots, et cela signifie que votre build ne jamais vérifier un place.

    Vous pouvez lire un peu plus sur les dépôts à Maven de la documentation sur Introduction aux Référentiels

    • Tout à fait d'accord, et fait sens pour les fourches vous voulez garder autour pendant un certain temps. Mais cela peut être beaucoup de frais généraux pour juste un petit patch à un projet existant.
    • Si elle est de courte durée, puis les amener à construire eux-mêmes. Vous pourrez toujours faire des compromis de ce genre.
    • Je doute que Github a un problème avec elle, comme ils ont écrit le plugin qui permet cette fonctionnalité. Je suis d'accord, c'est moins de l'idée, mais c est la vie.
    • Il n'est pas toujours possible de déployer un projet open source sur Sonatype. Par exemple, lorsque votre projet dépend d'un autre projet open source que ce n'est pas déjà déployé (et il ne peut pas être déployé, car il ne répond pas à la sonatype exigences).
    • ensuite, votre dépendance n'est pas vraiment open source. Vous devriez communiquer avec l'autre projet de l'expliquer et de les amener à résoudre leurs licences. (Le soleil a été à l'origine de ce comportement dans le passé)
    • Ce n'est pas une question de licence. Certains projet, le propriétaire décide de ne pas publier sur la centrale, tout simplement parce que ce n'est pas leur priorité. Votre chemin n'est pas possible dans le monde réel. Si vous voulez tester: convaincre ce à publier sur le Central, code.google.com/p/sd-dss . C'est un gros projet Open Source financé par l'UNION européenne la communauté 🙂
    • Puis poussez-le vous-même à la Centrale. Le Sonatype documentation décrit les étapes que vous avez besoin et si c'est vraiment open source quelqu'un peut le faire.
    • le UsageGuide lien est mort. Veuillez s'il vous plaît mettre à jour? Je pense que le nouvel emplacement est central.sonatype.org/pages/ossrh-guide.html
    • Corrigé, merci pour la cueillette jusqu'.
    • Il y a un autre problème avec le github solution: si quelqu'un veut utiliser votre truc, il veut être sûr que l'opération ne sera pas perdre de l'artefact, est arrêté ou que ce soit. La suppression d'un repo sur Gitrhub est facile. Il n'est pas facile sur la Centrale. Utilisation de github pour des mises à jour instantanées semble raisonnable si.
    • Comment un simple argument que l'utilisation de Github accélère les choses 10 fois pour un débutant? L'apprentissage, la pratique et le dépannage de maven central déploiements va prendre des années pour un novice. Il est totalement pas convivial
    • Comme indiqué dans la solution, un compromis est qu'il ralentit votre build pour chaque Maven Pensions que les besoins de la vérification. Si vous avez valide commentaires sur les problèmes d'utilisation de Maven Central poursuivra ensuite d'obtenir fixe. L'ajout de couches de solutions de contournement n'est pas la bonne réponse.
    • la découverte de la manière que les autres personnes de valeur et de réellement utiliser est le meilleur moyen. JS a été lent, en étroite étendue et disons pas grave plate-forme au début, maintenant c'est l'artefact système de déploiement des feuilles de Java loin derrière. Tout cela grâce à la communauté. Github représente la communauté et est facile à utiliser. L'autre chose, c'est Maven hébergé référentiel JFrog de Bintray gratuit et Open Source
    • Vous avez raison, après avoir essayé l'approche ci-dessus j'ai retrouvé avec grand uber-pots GitHub de l'API de la consommer et nous avons dû abandonner cette direction. Avec les limites et le temps qu'il faut télécharger sur GitHub, il m'a convaincu que GitHub est juste pas le bon outil. Quelqu'un a dit que GitHub fait ce plugin, ce qui est vrai, mais c'est vraiment pour GitHub Pages (qui sont de petite taille et pas un problème). L'hébergement de votre propre repo Maven ou peut-être l'un des pensions de services est le meilleur (bien que les services ne regarde pas des grands ou ils sont très chers).
    • cette option permettrait d'obtenir moins de downvotes si elle a effectivement expliqué pourquoi l'utilisation de github à base de pensions de titres, en particulier, est mauvais, au lieu de simplement la propagation de RUMEUR sur l'utilisation de plusieurs pensions de titres et de fichiers volumineux dans git en général
    • Merci pour vos commentaires. Pourriez-vous préciser de quelle manière les détails sous pourquoi 1) et 2) sont FUD. Ils sont clairement explicite les raisons pour lesquelles un github à base de repo est une mauvaise idée.
    • il est fud, car elle suppose que l') ayant de multiples repos est toujours mauvais, b) avoir des binaires dans tout repo git, c'est mauvais, et n'a rien à voir avec l'hébergement d'un repo maven sur github
    • Selon l'explication, a) ayant de multiples référentiels ralentit votre maven build, comme chaque artifiact est vérifiée pour chaque référentiel. Ce n'est pas FUD, c'est fait.b) git est conçu pour le contrôle de version, binaire artefacts sont sorties et quelque chose qui peut être régénéré, ils ne bénéficient de contrôle de version git de la différenciation des algorithmes, ils ont juste gonfler votre repo git et de ralentir les gens de clones. Mais je peux voir comment la réponse n'est pas explicitement l'expliquer.
    • Merci pour les commentaires, j'ai mis à jour le texte de réponse à inclure plus de détails.
    • GitHub introduit git-lfs.github.com la solution, qui coûte 5 $/mois pour 50 go de stockage et 50 GO de bande passante.
    • Qui est formidable à propos de git-epa, mais comment est-ce que l'adresse de vrais soucis je relance dans cette réponse? Il n'a pas. Si c'est open source, alors qu'il appartient à un seul des pensions de Maven Central.
    • il répond à votre souci de ne pas stocker les fichiers binaires dans git - et offre de façon appropriée les moyens de l'atténuer.
    • Juste assez, les ballonnements, cependant, est le moindre des soucis 🙂

    InformationsquelleAutor Bae
  3. 42

    Vous pouvez utiliser JitPack (gratuit pour le public, de dépôts Git) pour exposer votre dépôt GitHub comme un artefact Maven. Il est très facile. Vos utilisateurs doivent ajouter à leur pom.xml:

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

    Comme réponse à d'ailleurs l'idée est que JitPack sera de construire votre dépôt GitHub et de servir les pots. L'exigence est que vous avez un fichier de build et un GitHub libération.

    La bonne chose est que vous n'avez pas à gérer le déploiement et les téléchargements. Puisque vous ne voulez pas à jour votre propre artefact référentiel ses un bon match pour vos besoins.

    • JitPack est assez bonne, mais vous oblige à changer tous les id de groupe que vous avez autour. Ils disent que cela peut être évité, mais il exige que vous ajoutez une entrée dans le DNS de votre entreprise, ce qui est totalement impossible dans la plupart des cas. J'ai essayé avec JP une fois, puis j'ai décidé que c'est trop stupide pour aller de l'avant.
    • Modification de l'id de groupe de vos projets n'est pas nécessaire. Vous pouvez toujours installer ces projets à l'aide de com.github.L'utilisateur' groupId. Mais peut-être votre cas d'utilisation est différente.
    • Oui, c'est très bien. Parce que j'ai déjà des dizaines d'entre eux autour de mon organisation et les utilisateurs externes, et parce que je veux ma propre marque. Comment on peut être fou pour essayer de me forcer dans son propre id de groupe est l'une des choses pour lesquelles je suis la pensée de faire un changement de carrière.
    • De plus, je ne vois pas de réel besoin pour JP gars pour lancer une telle exigence à moi (ils pourraient intercepter Maven demandes à partir du référentiel spec).
    • Bien sûr, mais alors vous pouvez facilement de faux groupId et imaginez que vous êtes dans une autre organisation. GroupId doit être vérifiée en quelque sorte et enregistrements DNS est une façon de le faire. Comment voulez-vous y faire face?
    • Mais ce problème peut être résolu par d'autres moyens, par exemple en ajoutant /utilisateur /ou de l'organisation à l'adresse URL du référentiel. C'est effectivement quelque chose qui était déjà très bien dans Maven, je ne vois pas de raison logique pour introduire leur propre système de coordonnées, ce qui est impossible à respecter dans la plupart des situations. Et c'est une honte, la cause, pour le reste, JP est très cool.
    • Eh bien, cela semble raisonnable. Peut-être en ouvrir une demande de fonctionnalité?:)
    • Bonne idée, je l'ai fait: github.com/jitpack/jitpack.io/issues/209, merci 🙂

    InformationsquelleAutor Andrejs
  4. 8

    Une autre alternative est d'utiliser un hébergement web avec webdav. Vous aurez besoin de l'espace pour cela quelque part, bien sûr, mais il est simple à mettre en place et une bonne alternative à l'exécution d'une véritable serveur nexus.

    ajouter à votre section

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

    Ajouter quelque chose comme ceci à votre distributionManagement section

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

    Enfin, assurez-vous pour l'installation de l'accès au référentiel dans votre settings.xml

    l'ajouter à vos serveurs section

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

    et une définition de vos dépôts section

                <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 n'importe quel standard de php hosting, vous pouvez utiliser quelque chose comme sabredav pour ajouter des fonctionnalités webdav.

    Avantages: vous avez votre propre repository maven
    Inconvénients: vous ne disposez pas de la capacité de gestion dans nexus; vous avez besoin de quelques webdav de configuration quelque part

    InformationsquelleAutor Jilles van Gurp
  5. 7

    Comme une alternative, Bintray offre l'hébergement gratuit de dépôts maven. C'est probablement une bonne alternative à Sonatype OSS et Maven Central si vous ne veulent absolument pas renommer l'id de groupe. Mais s'il vous plaît, au moins faire un effort pour obtenir vos modifications intégrées en amont ou de les renommer et de les publier à la Centrale. Il rend beaucoup plus facile pour les autres d'utiliser votre fourche.

    • Je ne pouvais pas le croire quand j'ai essayé, mais Bintray ne prend pas en charge les instantanés. Inutile.
    • Ce n'est pas gratuit plus. 150 $par mois.
    • Je pense que c'est payant pour les projets de logiciels open source: jfrog.com/open-source
    InformationsquelleAutor Guillaume
  6. 0

    Si vous avez seulement aar ou jar fichier lui-même, ou tout simplement ne voulez pas utiliser les plugins: - j'ai créé un simple script shell. Vous pouvez réaliser la même chose avec elle - la publication de vos artefacts à Github et l'utiliser comme public repo Maven.

    InformationsquelleAutor Orest Savchak