Hospedar un repositorio Maven en github

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?

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

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

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

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>

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

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

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  

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.

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.