java - que - Maven: agregar una dependencia a un tarro por ruta relativa

mvn package

Question

Tengo un frasco de propietario que quiero agregar a mi pom como una dependencia.

Pero no quiero agregarlo a un repositorio. La razón es que quiero que mis comandos habituales de maven, como mvn compile , etc, funcionen de forma mvn compile . (Sin exigir a los desarrolladores que lo agreguen a algún repositorio por sí mismos).

Quiero que el archivo jar se encuentre en una biblioteca de terceros en el control de código fuente y se vincule a él mediante una ruta relativa desde el archivo pom.xml.

Se puede hacer esto? ¿Cómo?

Answer 1

Quiero que el archivo jar se encuentre en una biblioteca de terceros en el control de código fuente y se vincule a él mediante una ruta relativa desde el archivo pom.xml.

Si realmente desea esto (entienda, si no puede usar un repositorio corporativo), entonces mi consejo sería usar un "repositorio de archivos" local para el proyecto y no usar una dependencia del ámbito del system . El ámbito del system debe evitarse, tales dependencias no funcionan bien en muchas situaciones (por ejemplo, en el ensamblaje), causan más problemas que beneficios.

Entonces, en su lugar, declare un repositorio local para el proyecto:

<repositories>
<repository>
<id>my-local-repo</id>
<url>file://${basedir}/my-repo</url>
</repository>
</repositories>

Instale su localRepositoryPath terceros allí usando install:install-file con el parámetro localRepositoryPath :

mvn install:install-file -Dfile=<path-to-file> -DgroupId=<myGroup> /
-DartifactId=<myArtifactId> -Dversion=<myVersion> /
-Dpackaging=<myPackaging> -DlocalRepositoryPath=<path>

Actualización: parece que install:install-file ignora el localRepositoryPath cuando usa la versión 2.2 del complemento. Sin embargo, funciona con la versión 2.3 y posteriores del complemento. Entonces use el nombre completo del complemento para especificar la versión:

mvn org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file /
-Dfile=<path-to-file> -DgroupId=<myGroup> /
-DartifactId=<myArtifactId> -Dversion=<myVersion> /
-Dpackaging=<myPackaging> -DlocalRepositoryPath=<path>

documentación de plugin de instalación de maven

Finalmente, declare como cualquier otra dependencia (pero sin el alcance del system ):

<dependency>
<groupId>your.group.id</groupId>
<artifactId>3rdparty</artifactId>
<version>X.Y.Z</version>
</dependency>

En mi humilde opinión, esta es una mejor solución que usar un ámbito de system ya que su dependencia será tratada como un buen ciudadano (por ejemplo, se incluirá en una asamblea, etc.).

Ahora, tengo que mencionar que la "manera correcta" de lidiar con esta situación en un entorno corporativo (tal vez no sea el caso aquí) sería usar un repositorio corporativo.

Answer 2

Anteriormente he escrito sobre un patrón para hacer esto.

Es muy similar a la solución propuesta por Pascal, aunque mueve todas estas dependencias a un módulo de repositorio dedicado para que no tenga que repetirlo en todos los lugares en que se usa la dependencia si se trata de una compilación de múltiples módulos.

Answer 3

Básicamente, agregue esto al pom.xml:

...
<repositories>
<repository>
<id>lib_id</id>
<url>file://${project.basedir}/lib</url>
</repository>
</repositories>
...
<dependencies>
...
<dependency>
<groupId>com.mylibrary</groupId>
<artifactId>mylibraryname</artifactId>
<version>1.0.0</version>
</dependency>
...
</dependencies>

Answer 4

Este es otro método además de mi respuesta anterior en ¿Puedo agregar tarros a maven 2 build classpath sin instalarlos?

Esto evitará el límite cuando se utilicen construcciones de múltiples módulos, especialmente si se hace referencia al JAR descargado en proyectos secundarios fuera del padre. Esto también reduce el trabajo de configuración al crear los archivos POM y SHA1 como parte de la compilación. También permite que el archivo resida en cualquier parte del proyecto sin arreglar los nombres o seguir la estructura del repositorio de Maven.

Esto utiliza el complemento de instalación de Maven. Para que esto funcione, debe configurar un proyecto de múltiples módulos y tener un nuevo proyecto que represente la compilación para instalar archivos en el repositorio local y asegurarse de que uno sea el primero.

El proyecto pom.xml de varios módulos se vería así:

<packaging>pom</packaging>
<modules>
<!-- The repository module must be first in order to ensure
that the local repository is populated -->
<module>repository</module>
<module>... other modules ...</module>
</modules>

El archivo repositorio / pom.xml contendrá las definiciones para cargar los archivos JAR que forman parte de su proyecto. Los siguientes son algunos fragmentos del archivo pom.xml.

<artifactId>repository</artifactId>
<packaging>pom</packaging>

El paquete pom evita que esto realice pruebas, compile o genere ningún archivo jar. La carne del pom.xml está en la sección de compilación donde se usa el complemento de instalación de maven.

<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<executions>
<execution>
<id>com.ibm.db2:db2jcc</id>
<phase>verify</phase>
<goals>
<goal>install-file</goal>
</goals>
<configuration>
<groupId>com.ibm.db2</groupId>
<artifactId>db2jcc</artifactId>
<version>9.0.0</version>
<packaging>jar</packaging>
<file>${basedir}/src/jars/db2jcc.jar</file>
<createChecksum>true</createChecksum>
<generatePom>true</generatePom>
</configuration>
</execution>
<execution>...</execution>
</executions>
</plugin>
</plugins>
</build>

Para instalar más de un archivo, simplemente agregue más ejecuciones.

Answer 5

Esto está funcionando para mí: digamos que tengo esta dependencia

<dependency>
<groupId>com.company.app</groupId>
<artifactId>my-library</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/my-library.jar</systemPath>
</dependency>

Luego, agregue la ruta de clase para la dependencia de su sistema manualmente como esta

<Class-Path>libs/my-library-1.0.jar</Class-Path>

Configuración completa:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<archive>
<manifestEntries>
<Build-Jdk>${jdk.version}</Build-Jdk>
<Implementation-Title>${project.name}</Implementation-Title>
<Implementation-Version>${project.version}</Implementation-Version>
<Specification-Title>${project.name} Library</Specification-Title>
<Specification-Version>${project.version}</Specification-Version>
<Class-Path>libs/my-library-1.0.jar</Class-Path>
</manifestEntries>
<manifest>
<addClasspath>true</addClasspath>
<mainClass>com.company.app.MainClass</mainClass>
<classpathPrefix>libs/</classpathPrefix>
</manifest>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.5.1</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/libs/</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>

Answer 6

Puede usar eclipse para generar un archivo ejecutable Jar: Export / Runable Jar

Answer 7

Una pequeña adición a la solución publicada por Pascal.

Cuando seguí esta ruta, recibí un error en Maven al instalar el jar de ojdbc.

[INFO] --- maven-install-plugin:2.5.1:install-file (default-cli) @ validator ---
[INFO] pom.xml not found in ojdbc14.jar

Después de agregar -DpomFile, el problema fue resuelto.

$ mvn install:install-file -Dfile=./lib/ojdbc14.jar -DgroupId=ojdbc /
-DartifactId=ojdbc -Dversion=14 -Dpackaging=jar -DlocalRepositoryPath=./repo /
-DpomFile=~/.m2/repository/ojdbc/ojdbc/14/ojdbc-14.pom

Answer 8

Utilizando el ámbito del system . ${basedir} es el directorio de tu pom.

<dependency>
<artifactId>..</artifactId>
<groupId>..</groupId>
<scope>system</scope>
<systemPath>${basedir}/lib/dependency.jar</systemPath>
</dependency>

Sin embargo, es aconsejable que instale su jar en el repositorio, y no lo comprometa con el SCM; después de todo, eso es lo que maven intenta eliminar.

Answer 9

cambiamos a gradle y esto funciona mucho mejor en gradle;). solo especificamos una carpeta en la que podemos colocar los archivos jar para situaciones temporales como esa. Todavía tenemos la mayoría de nuestros frascos definidos en la sección de administración de dependencia típica (es decir, lo mismo que maven). Esta es solo una dependencia más que definimos.

así que, básicamente, ahora podemos dejar caer cualquier tarro que queramos en nuestro directorio lib para pruebas temporales si no se encuentra en un repositorio de Maven en algún lugar.