plugin mvn maven github github-pages mvn-repo

mvn - maven package docker build



Alojamiento de un repositorio Maven en github (6)

Como alternativa, Bintray ofrece hospedaje gratuito de repositorios de Maven. Probablemente sea una buena alternativa a Sonatype OSS y Maven Central si no quiere cambiar el nombre de groupId. Pero, al menos, haga un esfuerzo por integrar sus cambios en sentido ascendente o cambie su nombre y publique en Central. Hace que sea mucho más fácil para otros usar tu tenedor.

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 como 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 utilizando maven. ¿Cuál es la mejor manera de hacer esto?

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

  1. Cree una rama llamada mvn-repo para alojar sus artefactos Maven.
  2. Usa el plug site-maven-plugin github para empujar tus artefactos a github.
  3. Configure maven para usar su mvn-repo remoto como un repositorio maven.

Hay varios beneficios al usar este enfoque:

  • Los artefactos de Maven se mantienen separados de su fuente en una rama separada llamada mvn-repo , al igual que las páginas github se guardan en una rama separada llamada gh-pages (si usa páginas github)
  • A diferencia de otras soluciones propuestas, no está en conflicto con tus gh-pages si las estás utilizando.
  • Se vincula de forma natural con el objetivo de implementación, por lo que no hay nuevos comandos de Maven para aprender. Solo usa mvn deploy como lo harías normalmente

La forma típica en que implementa los artefactos en un repositorio remoto es mediante el uso de mvn deploy , así que mvn deploy ese mecanismo para esta solución.

Primero, dígale a maven que implemente artefactos en una ubicación de almacenamiento temporal dentro de su directorio objetivo. Agrega esto a tu 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 intente ejecutar mvn clean deploy . Verás que implementó tu repositorio de target/mvn-repo en target/mvn-repo . El siguiente paso es conseguir que cargue ese directorio en GitHub.

Agregue su información de autenticación a ~/.m2/settings.xml para que github site-maven-plugin pueda 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 ha indicado, asegúrese de hacer chmod 700 settings.xml para asegurarse de que nadie pueda leer su contraseña en el archivo. Si alguien sabe cómo hacer que el sitio solicite una contraseña en lugar de requerirlo en un archivo de configuración, deje que yo sé.)

Luego, informe al site-maven-plugin GitHub site-maven-plugin sobre 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-plugin para cargar desde su repositorio provisional temporal a su mvn-repo 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 rama mvn-repo no necesita existir, se creará para usted.

Ahora ejecute mvn clean deploy nuevamente. Debería ver que "maven-deploy-plugin" carga los archivos a su repositorio de almacenamiento local en el directorio de destino, luego el sitio-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 rama mvn-repo y verifique que todos sus archivos binarios estén ahora allí.

¡Felicidades!

Ahora puede implementar sus artefactos de mvn clean deploy repositorio público de un hombre pobre simplemente ejecutando mvn clean deploy .

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

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

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

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

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

agrega esto a tu sección de construcción

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

Agrega algo como esto a tu 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 configuración.xml

agrega esto a tu sección de servidores

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

y una definición a 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 tienes algún alojamiento php estándar, puedes usar algo como sabredav para agregar capacidades de webdav.

Ventajas: tiene su propio repositorio de Maven. Desventajas: no tiene ninguna de las capacidades de gestión en nexus; necesitas alguna configuración webdav en algún lugar

Puedes usar JitPack para exponer tu repositorio GitHub como un artefacto 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 elsewhere la idea es que JitPack construirá tu repo de GitHub y servirá a los frascos. El requisito es que tenga un archivo de compilación y una versión de GitHub.

Lo bueno es que no tienes que manejar la implementación y las cargas. Dado que no desea mantener su propio depósito de artefactos, es una buena opción para sus necesidades.

Si solo aar archivo aar o jar , o simplemente no quiere usar complementos, he creado un script de shell simple . Puede lograr lo mismo con él: publicar sus artefactos en Github y usarlos como representante público de Maven.

No uses GitHub como un repositorio de Maven.

Edición: esta opción recibe muchos votos a la baja, pero no hay comentarios sobre por qué. Esta es la opción correcta, independientemente de las capacidades técnicas para hospedar en GitHub. Alojarse en GitHub es incorrecto por todos los motivos que se describen a continuación y, sin comentarios, no puedo mejorar la respuesta para aclarar sus problemas.

Mejor Opción - Colaborar con el Proyecto Original.

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

Alternativa - Mantenga su propio tenedor

Ya 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 a Maven Central (lea la Guía para cargar artefactos en el Repositorio Central ) dándole un nuevo groupId y tal vez un nuevo.

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.

Realmente considere duro si un tenedor es la opción correcta. Lea los innumerables resultados de Google para ''por qué no se bifurcan''

Razonamiento

Inflar su repositorio con tarros aumenta el tamaño de la descarga sin ningún beneficio

Un frasco es una output de su proyecto, se puede regenerar en cualquier momento a partir de sus inputs , y su repositorio de GitHub debe contener solo inputs .

No me crees Luego, compruebe los resultados de Google para ''no almacenar binarios en git'' .

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

La definición de varios repositorios en su pom.xml ralentiza su compilación por el número de Repositorios veces Número de artefactos

Stephen Connolly says :

Si alguien agrega su repo, tendrá un impacto en el rendimiento de su compilación, ya que ahora tienen otro repo para verificar los artefactos contra ... No es un gran problema si solo tiene que agregar un repo ... 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.

¡Está bien! Maven debe verificar todos los artefactos (y sus dependencias) definidos en su pom.xml con cada Repositorio que haya definido , ya que una versión más nueva podría estar disponible en cualquiera de esos repositorios.

Pruébalo por ti mismo y sentirás el dolor de una constitución lenta.

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

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