¿Cómo agregar archivos jar locales a un proyecto Maven?
¿Cómo agrego archivos jar locales (que aún no forman parte del repositorio de Maven) directamente en las fuentes de la biblioteca de mi proyecto?
Puede agregar dependencias locales directamente (como se menciona en el proyecto build maven con bibliotecas de propiedad incluidas ) de esta manera:
<dependency>
<groupId>com.sample</groupId>
<artifactId>sample</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${project.basedir}/src/main/resources/Name_Your_JAR.jar</systemPath>
</dependency>
Actualizar
En las nuevas versiones, esta característica está marcada como obsoleta, pero aún funciona y no se elimina (solo ve una advertencia en el registro durante el inicio de Maven). Se plantea un problema en el grupo Maven sobre este https://issues.apache.org/jira/browse/MNG-6523 (puede participar y describir por qué esta función es útil en algunos casos). ¡Espero que esta característica permanezca ahí!
Si me lo preguntas, siempre y cuando no se elimine la función, uso esto para crear dependencia de un solo archivo jar travieso en mi proyecto que no cabe en el repositorio. Si se elimina esta característica, bueno, ¡hay muchas buenas respuestas aquí entre las que puedo elegir más adelante!
Instale el JAR en su repositorio local de Maven (normalmente .m2en su carpeta de inicio) de la siguiente manera:
mvn install:install-file \
-Dfile=<path-to-file> \
-DgroupId=<group-id> \
-DartifactId=<artifact-id> \
-Dversion=<version> \
-Dpackaging=<packaging> \
-DgeneratePom=true
Donde cada uno se refiere a:
<path-to-file>: la ruta al archivo a cargar, por ejemplo →c:\kaptcha-2.3.jar
<group-id>: el grupo en el que se debe registrar el archivo, por ejemplo →com.google.code
<artifact-id>: el nombre del artefacto para el archivo, por ejemplo →kaptcha
<version>: la versión del archivo, por ejemplo →2.3
<packaging>: el embalaje del archivo, por ejemplo →jar
Referencia
- Preguntas frecuentes de Maven: Tengo un frasco que quiero colocar en mi repositorio local. ¿Cómo puedo copiarlo?
- Uso del complemento de instalación de Maven: el
install:install-fileobjetivo
En primer lugar, me gustaría dar crédito por esta respuesta a un usuario anónimo de Stack Overflow; estoy bastante seguro de haber visto una respuesta similar aquí antes, pero ahora no puedo encontrarla.
La mejor opción para tener archivos JAR locales como dependencia es crear un repositorio Maven local. Un repositorio de este tipo no es más que una estructura de directorio adecuada con archivos pom.
Para mi ejemplo: tengo mi proyecto maestro en la ${master_project}ubicación y el subproyecto1 está activado ${master_project}/${subproject1}.
Luego creo un repositorio Maven en:
${master_project}/local-maven-repo.
En el archivo pom en el subproyecto1 ubicado en ${master_project}/${subproject1}/pom.xml, se debe especificar el repositorio que tomaría la ruta del archivo como parámetro de URL:
<repositories>
<repository>
<id>local-maven-repo</id>
<url>file:///${project.parent.basedir}/local-maven-repo</url>
</repository>
</repositories>
La dependencia se puede especificar como para cualquier otro repositorio. Esto hace que su repositorio pom sea independiente. Por ejemplo, una vez que el JAR deseado esté disponible en Maven central, solo necesita eliminarlo de su repositorio local y se extraerá del repositorio predeterminado.
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.servicebinder</artifactId>
<version>0.9.0-SNAPSHOT</version>
</dependency>
Lo último, pero no menos importante, es agregar el archivo JAR al repositorio local usando el modificador -DlocalRepositoryPath de esta manera:
mvn org.apache.maven.plugins:maven-install-plugin:2.5.2:install-file \
-Dfile=/some/path/on/my/local/filesystem/felix/servicebinder/target/org.apache.felix.servicebinder-0.9.0-SNAPSHOT.jar \
-DgroupId=org.apache.felix -DartifactId=org.apache.felix.servicebinder \
-Dversion=0.9.0-SNAPSHOT -Dpackaging=jar \
-DlocalRepositoryPath=${master_project}/local-maven-repo
Una vez instalado el archivo JAR, su repositorio de Maven se puede enviar a un repositorio de código y toda la configuración es independiente del sistema. ( Ejemplo de trabajo en GitHub ).
Estoy de acuerdo en que tener JAR comprometidos con el repositorio de código fuente no es una buena práctica, pero en la vida real, las soluciones rápidas y sucias a veces son mejores que un repositorio Nexus completo para alojar un JAR que no se puede publicar.
