Ospitare un repository Maven su github


312

Ho un fork di una piccola libreria open source su cui sto lavorando su Github. Vorrei renderlo disponibile ad altri sviluppatori tramite Maven, ma non voglio eseguire il mio server Nexus, e poiché è un fork non riesco facilmente a distribuirlo su oss.sonatype.org.

Quello che mi piacerebbe fare è distribuirlo su github in modo che altri possano accedervi usando Maven. Qual'è il miglior modo per farlo?


5
quali problemi di licenza stai affrontando in OSS Sonatype? Solo curioso da quando lo uso da solo.
Archimede Trajano,

5
C'è uno strumento che ti consente di esporre il tuo repository GitHub direttamente tramite Maven. jitpack.io stackoverflow.com/a/28483461/3975649
metrimer

1
Github ha anche annunciato un registro dei pacchetti che supporta Maven. Attualmente in beta pubblica: github.com/features/package-registry
Kaan

Risposte:


484

La migliore soluzione che sono riuscita a trovare consiste in questi passaggi:

  1. Crea un ramo chiamato mvn-repoper ospitare i tuoi manufatti maven.
  2. Usa il plug-in github site-maven per inviare i tuoi artefatti a github.
  3. Configurare Maven per usare il telecomando mvn-repocome repository Maven.

L'utilizzo di questo approccio comporta numerosi vantaggi:

  • Gli artefatti di Maven sono tenuti separati dalla tua fonte in un ramo separato chiamato mvn-repo, proprio come le pagine github sono mantenute in un ramo separato chiamato gh-pages(se usi pagine github)
  • A differenza di altre soluzioni proposte, non è in conflitto con le tue gh-pagesse le stai usando.
  • Si collega naturalmente con il target deploy quindi non ci sono nuovi comandi maven da imparare. Usa mvn deploycome faresti normalmente

Il modo tipico di distribuire gli artefatti in un repository remoto maven è usare mvn deploy, quindi cerchiamo di applicare il meccanismo per questa soluzione.

Innanzitutto, dire a Maven di distribuire artefatti in una posizione temporanea di staging all'interno della directory di destinazione. Aggiungi questo al tuo 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>

Ora prova a correre mvn clean deploy. Vedrai che ha distribuito il tuo repository Maven target/mvn-repo. Il prossimo passo è farlo caricare questa directory su GitHub.

Aggiungi le tue informazioni di autenticazione in ~/.m2/settings.xmlmodo che Github site-maven-pluginpossa inviare a 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>

(Come notato, assicurati di chmod 700 settings.xmlassicurarti che nessuno possa leggere la tua password nel file. Se qualcuno sa come richiedere una password per site-maven-plugin invece di richiederla in un file di configurazione, fammelo sapere.)

Quindi informa GitHub site-maven-plugindel nuovo server appena configurato aggiungendo quanto segue a pom:

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

Infine, configura il site-maven-plugincaricamento dal tuo repository temporaneo di gestione temporanea al tuo mvn-reporamo su 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>

Il mvn-reporamo non ha bisogno di esistere, sarà creato per te.

Ora corri di mvn clean deploynuovo. Dovresti vedere maven-deploy-plugin "carica" ​​i file nel tuo repository di staging locale nella directory di destinazione, quindi site-maven-plugin che commette quei file e li spinge sul server.

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

Visita github.com nel tuo browser, seleziona il mvn-reporamo e verifica che tutti i tuoi binari siano ora lì.

inserisci qui la descrizione dell'immagine

Congratulazioni!

Ora puoi distribuire i tuoi manufatti maven al repository pubblico di un uomo povero semplicemente correndo mvn clean deploy.

C'è un altro passo che vorrai fare, che è quello di configurare tutti i pom che dipendono dal tuo pom per sapere dove si trova il tuo repository. Aggiungi il frammento seguente al pom di qualsiasi progetto che dipende dal tuo progetto:

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

Ora qualsiasi progetto che richiede i tuoi file jar li scaricherà automaticamente dal tuo repository github maven.

Modifica: per evitare il problema menzionato nei commenti ('Errore durante la creazione del commit: richiesta non valida. Per' properties / name ', nil non è una stringa.'), Assicurati di indicare un nome nel tuo profilo su github.


25
Si noti inoltre che questa soluzione sovrascriverà gli artefatti precedenti ogni volta che si distribuisce. Questo è appropriato per i repository di snapshot, ma non per gli artefatti rilasciati. Per disabilitare quel comportamento, imposta la configurazione <merge>true</merge>del tuo plugin del sito. Se lo fai, però, penso che dovrai creare manualmente il ramo mvn-repo in github ed eliminare tutti i suoi file la prima volta.
emmby,

13
+1 intelligente e ben presentato. La mia unica critica è che non hai incluso un link al sito dei plugin Maven: github.com/github/maven-plugins . Grazie stavo cercando un modo per pubblicare il mio sito Maven su github!
Mark O'Connor,

7
Questo approccio non funziona quando si utilizza l'autenticazione a due fattori su github. Vedi la mia nota nel numero qui: github.com/github/maven-plugins/issues/36#issuecomment-31005606
Dag

18
Per farlo funzionare per progetti multi-modulo , puoi anche semplicemente usare <altDeploymentRepository>internal.repo::default::file://${user.dir}/target/mvn-repo</altDeploymentRepository>con il plugin maven-deploy e <outputDirectory>${user.dir}/target/mvn-repo</outputDirectory>con site-maven-plugin . Questo distribuirà tutti gli artefatti nel progetto root ("parent") e li spingerà nella rispettiva directory principale su github. Altrimenti, la build di ciascun sottomodulo sovrascriverà quella del sottomodulo costruito prima ...
sd

7
Due suggerimenti che lo fanno funzionare (almeno per me): Imposta la versione corrente del plugin Github (in questo momento sarebbe 0.11). Inoltre consiglierei a tutti di usare un token OAUTH invece della password. Puoi generarlo in "Impostazioni-> Applicazioni-> Token di accesso personali". Quindi puoi anche inserirlo nella POM tramite e archiviare il token come variabile di ambiente. <github.global.userName>YourUserName</github.global.userName> <github.global.password>${GITHUB_OAUTH_TOKEN</github.global.password>
Florian Loch,

120

Non usare GitHub come repository Maven.

Modifica: questa opzione ottiene molti voti negativi, ma non ci sono commenti sul perché. Questa è l'opzione corretta indipendentemente dalle capacità tecniche per ospitare effettivamente su GitHub. L'hosting su GitHub è sbagliato per tutti i motivi indicati di seguito e senza commenti non posso migliorare la risposta per chiarire i tuoi problemi.

Migliore opzione: collabora con il progetto originale

L'opzione migliore è convincere il progetto originale a includere le modifiche e attenersi all'originale.

Alternativa: mantieni la tua forcella

Dato che hai creato una libreria open source e che il tuo fork è anche open source, puoi caricare il tuo fork su Maven Central (leggi la Guida al caricamento di artefatti nel repository centrale ) dandogli un nuovo groupIde forse un nuovo artifactId.

Prendi in considerazione questa opzione solo se sei disposto a mantenere questo fork fino a quando le modifiche non vengono incorporate nel progetto originale e quindi dovresti abbandonarlo.

Valuta davvero se una forcella è l'opzione giusta. Leggi la miriade di risultati di Google per "why not to fork"

Ragionamento

Il gonfiamento del repository con i vasetti aumenta le dimensioni del download senza alcun vantaggio

Un vaso fa parte outputdel tuo progetto, può essere rigenerato in qualsiasi momento dal suo inputse il repository GitHub dovrebbe contenere solo inputs.

Non mi credi? Quindi controlla i risultati di Google per "non archiviare i binari in git" .

L'aiuto di GitHub Lavorare con file di grandi dimensioni ti dirà la stessa cosa. È vero che i jar non sono grandi ma sono più grandi del codice sorgente e una volta che un jar è stato creato da una versione non hanno motivo di essere versionato - ecco a cosa serve una nuova versione.

La definizione di più repository nel tuo pom.xml rallenta il tuo build di Numero di repository volte Numero di artefatti

Stephen Connolly dice :

Se qualcuno aggiunge il tuo repository, influiscono sulle prestazioni della build poiché ora hanno un altro repository per verificare gli artefatti ... Non è un grosso problema se devi solo aggiungere un repository ... Ma il problema cresce e la prossima cosa che conosci il tuo maven build sta controllando 50 repository per ogni artefatto e il tempo di costruzione è un cane.

Giusto! Maven deve controllare ogni artefatto (e le sue dipendenze) definiti nel tuo pom.xml rispetto a tutti i repository che hai definito , poiché una versione più recente potrebbe essere disponibile in uno di questi repository.

Provalo tu stesso e sentirai il dolore di una costruzione lenta.

Il posto migliore per i manufatti è in Maven Central, in quanto è il posto centrale per i barattoli, e questo significa che la tua build controllerà solo un posto.

Puoi leggere qualcosa in più sui repository nella documentazione di Maven su Introduzione ai repository


3
Totalmente d'accordo, e ha senso per le forcelle che vuoi tenere in giro per un po '. Ma questo può essere un sacco di spese generali solo per una piccola patch per un progetto esistente.
emmby

5
Dubito che Github abbia un problema, poiché hanno scritto il plug-in che abilita questa funzionalità. Sono d'accordo che non sia un'idea, ma c'est la vie.
Phy6,

4
Non è sempre possibile distribuire un progetto open source su Sonatype. Ad esempio, quando il tuo progetto dipende da un altro progetto open source che non è già stato distribuito (e non può essere distribuito perché non soddisfa i requisiti del sonatype).
Gab,

1
@Gab allora la tua dipendenza non è davvero open source. Dovresti contattare l'altro progetto e spiegarlo e indurlo a sistemare le loro licenze. (Sun era un colpevole di questo comportamento in passato)
Bae

1
@Bae Non è una questione di licenze. Alcuni proprietari di progetti decidono di non pubblicare su central semplicemente perché non è la loro priorità. La tua strada non è possibile nel mondo reale. Se vuoi provare: convincilo a pubblicare su Central code.google.com/p/sd-dss . È un grande progetto Open Source finanziato dalla comunità dell'UE :)
Gab

48

Puoi usare JitPack (gratuito per i repository Git pubblici) per esporre il tuo repository GitHub come artefatto Maven. È molto facile. I tuoi utenti dovrebbero aggiungere questo al loro pom.xml:

  1. Aggiungi repository:
<repository>
    <id>jitpack.io</id>
    <url>https://jitpack.io</url>
</repository>
  1. Aggiungi dipendenza:
<dependency>
    <groupId>com.github.User</groupId>
    <artifactId>Repo name</artifactId>
    <version>Release tag</version>
</dependency>

Come già detto altrove, l'idea è che JitPack costruirà il tuo repository GitHub e servirà i vasetti. Il requisito è che tu abbia un file build e una versione GitHub.

La cosa bella è che non devi gestire la distribuzione e i caricamenti. Dal momento che non volevi mantenere il tuo repository di artefatti è una buona corrispondenza per le tue esigenze.


JitPack è abbastanza buono, ma ti costringe a cambiare ogni gruppoId che hai in giro. Dicono che questo può essere evitato, ma richiede l'aggiunta di una voce al DNS della tua azienda, il che è totalmente impraticabile nella maggior parte dei casi. Ho provato con JP una volta, poi ho deciso che era troppo stupido per andare avanti.
zakmck,

1
Non è necessario modificare il gruppoId dei tuoi progetti. È comunque possibile installare tali progetti utilizzando il gruppoId "com.github.User". Ma forse il tuo caso d'uso è diverso.
Andrejs,

Sì, è molto Perché ne ho già decine intorno alla mia organizzazione e agli utenti esterni e perché voglio il mio marchio su di loro. Come si può essere così stupidi da provare a costringermi nel suo stesso gruppo L'Id è una delle cose per cui sto pensando di cambiare la mia carriera.
zakmck,

Inoltre, non vedo alcun reale bisogno per i ragazzi di JP di lanciarmi tale requisito (potrebbero semplicemente intercettare le richieste di Maven dalle specifiche del repository).
zakmck,

1
Buona idea, l'ho fatto: github.com/jitpack/jitpack.io/issues/209 , grazie :-)
zakmck

9

Un'altra alternativa è quella di utilizzare qualsiasi web hosting con supporto webdav. Ovviamente avrai bisogno di spazio per questo da qualche parte, ma è semplice da configurare e una buona alternativa all'esecuzione di un server Nexus completo.

aggiungi questo alla tua sezione di costruzione

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

Aggiungi qualcosa del genere alla tua sezione DistributionManagement

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

Assicurati infine di configurare l'accesso al repository in settings.xml

aggiungilo alla sezione dei tuoi server

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

e una definizione nella sezione dei repository

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

Infine, se hai un hosting php standard, puoi usare qualcosa come sabredav per aggiungere funzionalità webdav.

Vantaggi: hai il tuo repository maven Lati negativi: non hai nessuna capacità di gestione in nexus; hai bisogno di qualche configurazione di webdav da qualche parte


9

Dal 2019 è ora possibile utilizzare la nuova funzionalità denominata registro pacchetti Github .

Fondamentalmente il processo è:

  • genera un nuovo token di accesso personale dalle impostazioni di github
  • aggiungi repository e informazioni sul token nel tuo settings.xml
  • distribuire utilizzando

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

A partire dal 2019, questa è l'opzione migliore.
HRJ,

1
Ma per usarlo da qualcun altro, sembra che debba configurare settings.xml con i rispettivi URL e informazioni
sull'autorizzazione

Molto strano ...
Crei

Tuttavia, per i repository privati, dopo aver determinato determinati utilizzi / mese, i prezzi entrano in scena
Lokeshwar Tailor

8

In alternativa, Bintray offre hosting gratuito di repository Maven. Questa è probabilmente una buona alternativa a Sonatype OSS e Maven Central se non vuoi assolutamente rinominare il groupId. Ma per favore, almeno fai uno sforzo per integrare le modifiche a monte o rinominarle e pubblicarle in Central. Rende molto più facile per gli altri usare la forcella.


3
Non ci potevo credere quando ho provato, ma Bintray non supporta le istantanee. Inutili.
zakmck,

6
Non è più gratuito. $ 150 al mese.
AndroidDev,

Penso che sia una tassa per i progetti software open source: jfrog.com/open-source
iBiber

0

Se hai solo aaro jarfile stesso, o semplicemente non vuoi usare plugin, ho creato un semplice script di shell . Puoi ottenere lo stesso risultato pubblicando i tuoi artefatti su Github e utilizzandolo come repository Maven pubblico.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.