Maven: mantener tarros dependientes en el control de la versión del proyecto

Question

Por lo tanto, tengo un proyecto de guerra con varios tarros dependientes que no están disponibles en ningún repositorio. Hasta hace poco, los mantenía en src/main/webapp/WEB-INF/lib y los añadía al pom con system scope.

Entiendo que eso sea problemático, así que estoy buscando limpiar mi construcción. He instalado semi-manualmente los frascos en mi .m2/repository a través del plugin install:install-file. Eso es genial para mí, pero ¿qué hay de las otras personas en mi equipo? Somos pequeños, y configurar Nexus no es realmente una opción para nosotros. He recurrido a agregar comentarios al pom.xml explicando cómo ejecutar install:install-file para cada jar.

estoy bien con la solución install:install-file, pero todavía me gustaría a incluyen estos artefactos en el control de versiones de mi proyecto, y no sólo han roció sobre mi sistema de archivos.

Mantenerlos en src/main/webapp/WEB-INF/lib no funciona, ya que eso los agrega automáticamente al artefacto de guerra resultante (digresión: si maven simplemente continuara y los agregara al classpath aquí estaría listo, sin necesidad de instalarlo: instalar en archivos)

pregunta: hay un lugar, sancionada con la disposición de directorios experta en donde puedo meter estos archivos .jar, sólo para que yo puedo mantenerlos como parte de mi proyecto?

soy consciente de lo que está pasando aquí-Maven está tratando de mantener los frascos dependientes fuera de mi compilación por lo que cuando otros proyectos dependen de mi construcción, que puedan resolver las dependencias transitivas. Eso es genial para los proyectos de código abierto que están entrando en los repositorios de maven público, pero apostaría a que la gran mayoría de las personas que usan Maven están trabajando en proyectos de "hoja" como este, y sería muy útil tener una forma de hacerlo. para incluir archivos jar como parte del proyecto sin saltar tantos aros.

Answer 1

Si la creación de Nexus o simplemente un simple servidor de archivos de recompra según lo sugerido por Jan es muy demasiados problemas, aquí hay algunas otras opciones:

• basta con incluir los archivos JAR y un script que va a instalarlos todo en un directorio de su elección en control de versiones. No es necesario que la estructura de Maven lo sancione.
• Utilice su sistema de control de versiones como host para el repositorio, ya sea en una rama por sí mismo en su proyecto principal o como un proyecto separado. Permita que cualquier copia de seguridad, seguridad, etc. que ya tenga en el control de versiones se aplique al repositorio sin incluir los archivos jar en el conjunto de archivos que realmente se están revisando y comprometiendo.
• Incluya los archivos JAR en una carpeta que actúa como un mini repositorio que está prestado con el resto del código. Haga que pom.xml señale a esa carpeta como un repositorio que usa. No estoy 100% seguro de que esto sea posible, pero parece que sí lo es.

Answer 2

Creo que la mejor solución en su caso sería configurar un interno repositorio. No hay necesidad de configurar todo el Nexus al principio. Cualquier servidor web simple será suficiente o una carpeta compartida en alguna parte.

Compruebe el Maven DOC sobre cómo configurar un repositorio interno.

Answer 3

En mi empresa estamos usando Archiva, es el administrador de repositorio más simple de configurar y mantener.Especialmente si vas con la versión independiente. La cada desarrollador simplemente establece un profile en su archivo ~/.m2/settings.xml señalar al repositorio interno. Si esto es demasiado problema, sólo hay que poner el repositorio interno en el <repositories/> en el pom.xml directamente, sino que es realmente una mala práctica. Si la URL del repositorio se mueve alguna vez, debe actualizar todos sus proyectos pom.xml. Donde usar settings.xml pone esa carga en el desarrollador para actualizar su configuración local.

<?xml version="1.0" encoding="UTF-8"?> 
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> 
    <profiles> 
     <profile> 
      <id>internal</id> 
      <activation> 
       <activeByDefault>true</activeByDefault> 
      </activation> 
      <repositories> 
       <repository> 
        <id>mycompany.internal</id> 
        <name>Internal Release Repository</name> 
        <url>http://maven.mycompany.com/repository/internal/</url> 
        <releases> 
         <enabled>true</enabled> 
        </releases> 
        <snapshots> 
         <enabled>false</enabled> 
        </snapshots> 
       </repository> 
       <repository> 
        <id>mycompany.snapshots</id> 
        <name>Internal Snapshot Repository</name> 
        <url>http://maven.mycompany.com/repository/snapshots/</url> 
        <releases> 
         <enabled>false</enabled> 
        </releases> 
        <snapshots> 
         <enabled>true</enabled> 
        </snapshots> 
       </repository> 
      </repositories> 
     </profile> 
    </profiles> 


    <servers> 
     <server> 
      <id>internal</id> 
      <username>guest</username> 
     </server> 
     <server> 
      <id>snapshots</id> 
      <username>guest</username> 
     </server> 
    </servers> 

</settings> 

Si la creación de un Repository Manager es demasiado problema, creo que es necesario reconsiderar la alternativa de cosas añadiendo manualmente a su repositorio local con la mano, lo que es muy propenso a errores y consume mucho tiempo. Ejecuto una instancia de Archiva para mi desarrollo personal simplemente porque es muy fácil agregar el complemento release y administrar las versiones sin tener que recordar todas las opciones -D arcanas requeridas para agregar cosas a su repositorio local en cada máquina. Copiar el archivo ~/.m2/settings.xml es muy fácil y, si funciona en una sola máquina, funciona en todos ellos.

Esto es lo que agrega a su pom.xml para habilitar automáticamente las versiones y empujar artefactos a un repositorio, en mi caso es Archiva.

<distributionManagement> 
    <repository> 
     <id>internal</id> 
     <name>Internal Archiva Repository</name> 
     <url>http://maven.mycompany.com/repository/internal/</url> 
     <layout>default</layout> 
     <uniqueVersion>false</uniqueVersion> 
    </repository> 
    <snapshotRepository> 
     <id>snapshots</id> 
     <name>Internal Archiva Repository</name> 
     <url>http://maven.mycompany.com/repository/snapshots/</url> 
     <layout>default</layout> 
     <uniqueVersion>false</uniqueVersion> 
    </snapshotRepository> 
</distributionManagement> 

Entonces todo lo que hacemos es mvn clean release:prepare para actualizar automáticamente su versión pom.xmlcheque en, etiqueta y opcionalmente rama la liberación y empaquetar todos los artefactos, y luego mvn release:perform para empujar los artefactos para el control remoto repositorio y compruebe el recién versionado pom.xml y ya está listo para la próxima versión para comenzar el desarrollo.

Las instantáneas llegaron a snaphots y las Versiones van al internal automáticamente con el complemento de liberación. También debe configurar el conector scm, pero son solo unas líneas de configuración que solo debe tocar una vez. .

Esto es lo que parece para git, estamos utilizando Gitorious como nuestro Gerente de repositorio Git

<scm> 
    <connection>scm:git:git://gitorious.mycompany.com:myproject/myproject.git</connection> 
    <developerConnection>scm:git:ssh://git@gitorious.mycompany.com/myproject/myproject.git</developerConnection> 
    <url>http://gitorious.mycompany.com/myproject/myproject</url> 
</scm> 

Un ordenador de sobremesa edad que se ejecutan Linux puede controlar las tareas de depósito como este por un equipo de desarrollo sin tener que involucrar la adquisición y IT.

Answer 4

No lo he usado en la vida real, pero parece estar funcionando: simplemente inserte un repositorio dentro de su árbol de fuentes (usando install: install-file, supongo) y e instálelo. Use una entrada para apunta a ese repositorio. pom, así:

<?xml version="1.0" encoding="utf-8"?> 
<project> 
    <modelVersion>4.0.0</modelVersion> 
    <name>Depending project</name> 

    <groupId>com.example</groupId> 
    <artifactId>dependent</artifactId> 
    <version>0.9</version> 
    <packaging>jar</packaging> 

    <dependencies> 
    <dependency> 
     <groupId>com.example</groupId> 
     <artifactId>dependency</artifactId> 
     <version>0.9.3</version> 
     <type>jar</type> 
    </dependency> 
    </dependencies> 

    <repositories> 

    <repository> 
     <id>project-specific-deps</id> 
     <name>project-specific-deps</name> 
     <url>file:///${basedir}/repo</url> 
    </repository> 

    </repositories> 

</project> 

Ejemplo árbol de este modo:

. 
|-- pom.xml 
|-- repo 
| `-- com 
|  `-- example 
|   `--dependency 
|    |-- 0.9.3 
|    | |-- dependency-0.9.3.jar 
|    | |-- dependency-0.9.3.jar.md5 
|    | |-- dependency-0.9.3.jar.sha1 
|    | |-- dependency-0.9.3.pom 
|    | |-- dependency-0.9.3.pom.md5 
|    | `-- dependency-0.9.3.pom.sha1 
|    |-- maven-metadata.xml 
|    |-- maven-metadata.xml.md5 
|    `-- maven-metadata.xml.sha1 
|-- src 
| `-- main 
|  `-- java 
|   `-- com 
|    `-- example 
|     `-- dependent 
|      `-- Foobar.java 

¿Qué le parece?

Para completar:

$ mvn -version 
Apache Maven 2.2.1 (rdebian-4) 
Java version: 1.6.0_20 
Java home: /usr/lib/jvm/java-6-sun-1.6.0.20/jre 
Default locale: sv_SE, platform encoding: ISO-8859-1 
OS name: "linux" version: "2.6.32-3-686" arch: "i386" Family: "unix" 

Answer 5

Hay un montón de buenas respuestas aquí ya, y usted debe considerar seriamente la creación de un administrador de repositorio como Archiva para su grupo, ya que va a proporcionar otros beneficios, tanto ahora como durante hora.

Sin embargo, para responder directamente a su pregunta, aquí es un patrón para el almacenamiento de las dependencias de control de versiones con Maven: http://brettporter.wordpress.com/2009/06/10/a-maven-friendly-pattern-for-storing-dependencies-in-version-control/

Por favor, tenga en cuenta la advertencia de que limita el proyecto de ser utilizado autónomo en sí - si Si desea compartirlo como una dependencia para otros proyectos de Maven, aún necesitará configurar un repositorio.