Hospedar un repositorio Maven en github


312

Tengo un tenedor de una pequeña biblioteca de código abierto en la que estoy trabajando en github. Me gustaría ponerlo a disposición de otros desarrolladores a través de Maven, pero no quiero ejecutar mi propio servidor Nexus, y debido a que es una bifurcación, no puedo implementarlo fácilmente en oss.sonatype.org.

Lo que me gustaría hacer es implementarlo en Github para que otros puedan acceder a él usando Maven. ¿Cuál es la mejor manera de hacer esto?


55
¿Qué problemas de licencia tiene en OSS Sonatype? Solo curiosidad ya que lo uso yo mismo.
Arquímedes Trajano

55
Hay una herramienta que le permite exponer su repositorio de GitHub a través de Maven directamente. jitpack.io stackoverflow.com/a/28483461/3975649
metrimer

1
Github también anunció un registro de paquetes que admite maven. Actualmente en versión beta pública: github.com/features/package-registry
Kaan

Respuestas:


484

La mejor solución que he podido encontrar consiste en estos pasos:

  1. Crea una rama llamada mvn-repopara alojar tus artefactos maven.
  2. Use el github site-maven-plugin para empujar sus artefactos a github.
  3. Configure maven para usar su control remoto mvn-repocomo repositorio maven.

Existen varios beneficios al usar este enfoque:

  • Los artefactos Maven se mantienen separados de su fuente en una rama separada llamada mvn-repo, al igual que las páginas github se mantienen en una rama separada llamada gh-pages(si usa páginas github)
  • A diferencia de otras soluciones propuestas, no entra en conflicto con usted gh-pagessi las está utilizando.
  • Se vincula naturalmente con el objetivo de despliegue para que no haya nuevos comandos maven para aprender. Solo úsalo mvn deploycomo lo harías normalmente

La forma típica de implementar artefactos en un repositorio remoto de Maven es usar mvn deploy , así que vamos a conectar ese mecanismo para esta solución.

Primero, dígale a Maven que despliegue artefactos en una ubicación de almacenamiento temporal dentro de su directorio de destino. Agregue esto a su 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>

Ahora intenta correr mvn clean deploy. Verás que desplegó tu repositorio maven en target/mvn-repo. El siguiente paso es conseguir que cargue ese directorio en GitHub.

Agregue su información de autenticación para ~/.m2/settings.xmlque el github site-maven-pluginpueda enviar 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>

(Como se señaló, asegúrese de chmod 700 settings.xmlque nadie pueda leer su contraseña en el archivo. Si alguien sabe cómo hacer que el sitio-maven-plugin solicite una contraseña en lugar de solicitarla en un archivo de configuración, hágamelo saber).

Luego dígale a GitHub site-maven-pluginsobre el nuevo servidor que acaba de configurar agregando lo siguiente a su pom:

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

Finalmente, configure el site-maven-pluginpara cargar desde su repositorio temporal en su mvn-reposucursal en 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-reporama no necesita existir, se creará para usted.

Ahora corre de mvn clean deploynuevo. Debería ver que maven-deploy-plugin "carga" los archivos a su repositorio de almacenamiento local en el directorio de destino, luego site-maven-plugin confirma esos archivos y los envía al servidor.

[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 en su navegador, seleccione la mvn-reposucursal y verifique que todos sus archivos binarios estén allí.

ingrese la descripción de la imagen aquí

¡Felicidades!

Ahora puede desplegar sus artefactos expertos en el repositorio público de un hombre pobre simplemente ejecutando mvn clean deploy.

Hay un paso más que querrás dar, que es configurar cualquier poms que dependa de tu pom para saber dónde está tu repositorio. Agregue el siguiente fragmento al pom de cualquier proyecto que dependa de su proyecto:

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

Ahora, cualquier proyecto que requiera sus archivos jar los descargará automáticamente de su repositorio github maven.

Editar: para evitar el problema mencionado en los comentarios ('Error al crear confirmación: solicitud no válida. Para' propiedades / nombre ', nil no es una cadena'), asegúrese de indicar un nombre en su perfil en github.


25
Tenga en cuenta también que esta solución sobrescribirá sus artefactos anteriores cada vez que implemente. Esto es apropiado para repositorios de instantáneas, pero no para artefactos publicados. Para deshabilitar ese comportamiento, establezca la configuración <merge>true</merge>de su sitio-maven-plugin. Sin embargo, si haces eso, creo que tendrás que crear manualmente la rama mvn-repo en github y eliminar todos sus archivos la primera vez.
emmby

13
+1 inteligente y bien presentado. Mi única crítica es que no incluiste un enlace al sitio de complementos de Maven: github.com/github/maven-plugins . ¡Estaba buscando una manera de publicar mi sitio Maven en github!
Mark O'Connor

77
Este enfoque no funciona cuando se usa la autenticación de dos factores en github. Vea mi nota en el número aquí: github.com/github/maven-plugins/issues/36#issuecomment-31005606
Dag

18
Para que esto funcione en proyectos de módulos múltiples , también puede usarlo simplemente <altDeploymentRepository>internal.repo::default::file://${user.dir}/target/mvn-repo</altDeploymentRepository>con el complemento maven-deploy y <outputDirectory>${user.dir}/target/mvn-repo</outputDirectory>con el complemento site-maven . Esto desplegará todos los artefactos en el proyecto raíz ("padre") y los enviará al directorio padre respectivo en github. De lo contrario, la compilación de cada submódulo sobrescribirá la del submódulo construido antes ...
sd

77
Dos sugerencias que lo hacen funcionar (al menos para mí): establezca la versión actual del complemento Github (en este momento sería 0.11). También sugeriría que todos usen un token OAUTH en lugar de la contraseña. Puede generarlo en 'Configuración-> Aplicaciones-> Tokens de acceso personal'. Entonces también puede incorporarlo al POM a través de y almacenar el token como variable de entorno. <github.global.userName>YourUserName</github.global.userName> <github.global.password>${GITHUB_OAUTH_TOKEN</github.global.password>
Florian Loch

120

No use GitHub como repositorio Maven.

Editar: esta opción recibe muchos votos negativos, pero no hay comentarios sobre por qué. Esta es la opción correcta independientemente de las capacidades técnicas para alojar realmente en GitHub. Hospedar en GitHub es incorrecto por todas las razones que se detallan a continuación y sin comentarios no puedo mejorar la respuesta para aclarar sus problemas.

La mejor opción: colaborar con el proyecto original

La mejor opción es convencer al proyecto original para que incluya sus cambios y se adhiera al original.

Alternativa: mantenga su propio tenedor

Dado que ha bifurcado una biblioteca de código abierto, y su bifurcación también es de código abierto, puede cargar su bifurcación en Maven Central (lea la Guía para cargar artefactos en el Repositorio central ) dándole una nueva groupIdy tal vez una nuevaartifactId .

Solo considere esta opción si está dispuesto a mantener esta bifurcación hasta que los cambios se incorporen al proyecto original y luego debe abandonar esta.

Considere realmente si un tenedor es la opción correcta. Lea los innumerables resultados de Google para "por qué no bifurcar"

Razonamiento

Inflar el repositorio con frascos aumenta el tamaño de descarga sin beneficio

Un jar es parte outputde su proyecto, puede regenerarse en cualquier momento a partir de él inputs, y su repositorio de GitHub solo debe contenerinputs .

No me creas Luego verifique los resultados de Google para 'no almacenar binarios en git' .

Ayuda de GitHub Trabajar con archivos grandes le dirá lo mismo. Es cierto que los jar no son grandes, pero son más grandes que el código fuente y una vez que un jar ha sido creado por una versión, no tienen ninguna razón para ser versionados, para eso es para lo que sirve una nueva versión.

La definición de múltiples repos en su pom.xml ralentiza su construcción por Número de repositorios veces Número de artefactos

Stephen Connolly dice :

Si alguien agrega su repositorio, impactan su rendimiento de construcción ya que ahora tienen otro repositorio para verificar los artefactos ... No es un gran problema si solo tiene que agregar un repositorio ... Pero el problema crece y lo siguiente que sabe es su Maven Build está comprobando 50 repos para cada artefacto y el tiempo de construcción es un perro.

¡Así es! Maven necesita verificar cada artefacto (y sus dependencias) definidos en su pom.xml contra cada Repositorio que haya definido , ya que una versión más nueva podría estar disponible en cualquiera de esos repositorios.

Pruébelo usted mismo y sentirá el dolor de una construcción lenta.

El mejor lugar para los artefactos es Maven Central, ya que es el lugar central para los frascos, y esto significa que su construcción solo verificará un lugar.

Puede leer más sobre los repositorios en la documentación de Maven en Introducción a los repositorios


3
Totalmente de acuerdo, y tiene sentido para las horquillas que desea mantener por un tiempo. Pero esto puede ser una gran carga para un pequeño parche para un proyecto existente.
emmby

55
Dudo que Github tenga un problema, ya que escribieron el complemento que habilita esta capacidad. Estoy de acuerdo en que es menos que una idea, pero c'est la vie.
Phy6

44
No siempre es posible implementar un proyecto de código abierto en Sonatype. Por ejemplo, cuando su proyecto depende de otro proyecto de código abierto que aún no se ha implementado (y no se puede implementar porque no cumple con los requisitos de sonatype).
Gab

1
@Gab, entonces tu dependencia no es realmente de código abierto. Debe comunicarse con el otro proyecto y explicar esto y hacer que arreglen sus licencias. (Sun fue el culpable de este comportamiento en el pasado)
Bae

1
@Bae No se trata de licencias. Algunos propietarios de proyectos deciden no publicar en Central simplemente porque no es su prioridad. Tu camino no es posible en el mundo real. Si desea probar: convencerlo para que publique en Code.google.com/p/sd-dss Central . Es un gran proyecto de código abierto financiado por la comunidad de la UE :)
Gab

48

Puede usar JitPack (gratuito para repositorios públicos de Git) para exponer su repositorio de GitHub como un artefacto de Maven. Es muy fácil. Sus usuarios necesitarían agregar esto a su pom.xml:

  1. Añadir repositorio:
<repository>
    <id>jitpack.io</id>
    <url>https://jitpack.io</url>
</repository>
  1. Añadir dependencia:
<dependency>
    <groupId>com.github.User</groupId>
    <artifactId>Repo name</artifactId>
    <version>Release tag</version>
</dependency>

Como se respondió en otra parte, la idea es que JitPack construirá su repositorio de GitHub y servirá los frascos. El requisito es que tenga un archivo de compilación y una versión de GitHub.

Lo bueno es que no tiene que manejar la implementación y las cargas. Dado que no quería mantener su propio repositorio de artefactos, es una buena combinación para sus necesidades.


JitPack es bastante bueno, pero te obliga a cambiar cada ID de grupo que tienes alrededor. Dicen que esto se puede evitar, pero requiere que agregue una entrada al DNS de su empresa, lo cual es totalmente poco práctico en la mayoría de los casos. He intentado con JP una vez, luego decidí que esto es demasiado estúpido para seguir adelante.
zakmck

1
No es necesario cambiar el ID de grupo de sus proyectos. Todavía puede instalar esos proyectos usando 'com.github.User' groupId. Pero quizás su caso de uso es diferente.
Andrejs

Si, es mucho. Porque ya tengo decenas de ellos en mi organización y usuarios externos, y porque quiero mi propia marca en ellos. Cómo uno puede ser tan tonto para tratar de forzarme a su propio grupo Id es una de las cosas por las que estoy pensando en hacer un cambio de carrera.
zakmck

Además, no veo ninguna necesidad real de que los chicos de JP me arrojen ese requisito (podrían interceptar las solicitudes de Maven desde la especificación del repositorio).
zakmck

1
Buena idea, lo he hecho: github.com/jitpack/jitpack.io/issues/209 , gracias :-)
zakmck

9

Otra alternativa es utilizar cualquier alojamiento web con soporte webdav. Necesitará algo de espacio para esto en algún lugar, por supuesto, pero es sencillo de configurar y una buena alternativa para ejecutar un servidor nexus completo.

agregue esto a su sección de compilación

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

Agregue algo como esto a su sección de administración de distribución

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

Finalmente, asegúrese de configurar el acceso al repositorio en su settings.xml

agregue esto a la sección de sus servidores

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

y una definición para tu sección de repositorios

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

Finalmente, si tiene un hosting php estándar, puede usar algo como sabredav para agregar capacidades webdav.

Ventajas: tiene su propio repositorio maven. Desventajas: no tiene ninguna de las capacidades de administración en nexus; necesita alguna configuración de webdav en alguna parte


9

Desde 2019, ahora puede usar la nueva funcionalidad llamada registro de paquetes de Github .

Básicamente el proceso es:

  • generar un nuevo token de acceso personal desde la configuración de github
  • agregue información de repositorio y token en su settings.xml
  • desplegar usando

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

A partir de 2019, esta es la mejor opción.
HRJ

1
Pero por usarlo por otra persona, parece que él / ella necesita configurar settings.xml con la respectiva URL e información de autenticación
hemu

Muy extraño ... Usted crea su paquete público, pero otras personas necesitan autenticación antes de obtenerlo
Afectuoso

Sin embargo, para repositorios privados, después de ceder usos / mes, el precio aparece en la imagen
Lokeshwar Tailor

8

Como alternativa, Bintray ofrece alojamiento gratuito de repositorios maven. Probablemente sea una buena alternativa a Sonatype OSS y Maven Central si no desea cambiar el nombre de groupId. Pero, por favor, al menos haga un esfuerzo para integrar sus cambios corriente arriba o cambie el nombre y publíquelo en Central. Hace que sea mucho más fácil para otros usar su tenedor.


3
No lo podía creer cuando lo intenté, pero Bintray no admite instantáneas. Inútil.
zakmck

66
Ya no es gratis. $ 150 por mes.
AndroidDev

Creo que es una tarifa para proyectos de software de código abierto: jfrog.com/open-source
iBiber

0

Si sólo tiene aaro jararchivo en sí, o simplemente no desea utilizar plugins - He creado un simple script de shell . Puede lograr lo mismo con él: publicar sus artefactos en Github y usarlo como repositorio público de Maven.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.