Pregunta ¿Puedo agregar jar a maven 2 classpath build sin instalarlos?


Maven2 me está volviendo loco durante la fase de experimentación / maqueta rápida y sucia del desarrollo.

tengo un pom.xml archivo que define las dependencias para el marco de la aplicación web que quiero usar, y puedo generar rápidamente proyectos iniciales a partir de ese archivo. Sin embargo, a veces quiero vincular a una biblioteca de terceros que aún no tiene una pom.xml archivo definido, por lo que en lugar de crear el pom.xml archivo para la lib de terceros a mano e instálelo, y agregue la dependencia a mi pom.xml, Me gustaría decirle a Maven: "Además de mis dependencias definidas, incluye las jarras que están en /lib también."

Parece que esto debería ser simple, pero si lo es, me falta algo.

Cualquier sugerencia sobre cómo hacer esto es muy apreciada. Aparte de eso, si hay una manera simple de señalar Maven a un /lib directorio y crear fácilmente un pom.xml con todos los jars adjuntos mapeados a una única dependencia que podría nombrar / instalar y vincular de una sola vez también sería suficiente.


647
2017-12-12 20:57


origen


Respuestas:


Problemas de enfoques populares

La mayoría de las respuestas que encontrará en Internet le sugerirán instalar la dependencia en su repositorio local o especificar un alcance de "sistema" en el pom y distribuya la dependencia con la fuente de su proyecto. Pero ambas soluciones son defectuosas.

Por qué no debes aplicar el enfoque "Instalar a Repo Local"

Cuando instala una dependencia en su repositorio local, permanece allí. Su artefacto de distribución funcionará bien siempre que tenga acceso a este repositorio. El problema es que en la mayoría de los casos este repositorio residirá en su máquina local, por lo que no habrá forma de resolver esta dependencia en ninguna otra máquina. Claramente, hacer que su artefacto dependa de una máquina específica no es una forma de manejar las cosas. De lo contrario, esta dependencia tendrá que instalarse localmente en cada máquina que trabaje con ese proyecto, que no es mejor.

Por qué no debes aplicar el enfoque de "Alcance del sistema"

Los frascos de los que depende con el enfoque "Alcance del sistema" no se instalan en ningún repositorio ni se adjuntan a sus paquetes de destino. Es por eso que su paquete de distribución no tendrá una manera de resolver esa dependencia cuando se use. Esa es la razón por la cual el uso del alcance del sistema incluso se desaprovechó. De todos modos, no quiere confiar en una característica en desuso.

La solución de repositorio estática en el proyecto

Después de poner esto en su pom:

<repository>
    <id>repo</id>
    <releases>
        <enabled>true</enabled>
        <checksumPolicy>ignore</checksumPolicy>
    </releases>
    <snapshots>
        <enabled>false</enabled>
    </snapshots>
    <url>file://${project.basedir}/repo</url>
</repository>

para cada artefacto con una identificación de grupo de forma x.y.z Maven incluirá la siguiente ubicación dentro de su directorio de proyecto en su búsqueda de artefactos:

repo/
| - x/
|   | - y/
|   |   | - z/
|   |   |   | - ${artifactId}/
|   |   |   |   | - ${version}/
|   |   |   |   |   | - ${artifactId}-${version}.jar

Para elaborar más sobre esto, puedes leer esta publicación en el blog.

Utilice Maven para instalar el repositorio del proyecto

En lugar de crear esta estructura a mano, recomiendo utilizar un plugin Maven para instalar sus jarras como artefactos. Entonces, para instalar un artefacto en un repositorio dentro del proyecto bajo repocarpeta ejecutar:

mvn install:install-file -DlocalRepositoryPath=repo -DcreateChecksum=true -Dpackaging=jar -Dfile=[your-jar] -DgroupId=[...] -DartifactId=[...] -Dversion=[...]

Si elige este enfoque, podrá simplificar la declaración del repositorio en pom a:

<repository>
    <id>repo</id>
    <url>file://${project.basedir}/repo</url>
</repository>

Una secuencia de comandos de ayuda

Dado que ejecutar el comando de instalación para cada lib es algo molesto y definitivamente propenso a errores, he creado un script de utilidad que instala automáticamente todos los frascos de una lib carpeta a un repositorio de proyecto, mientras se resuelven automáticamente todos los metadatos (groupId, artifactId y etc.) de los nombres de los archivos. El script también imprime las dependencias xml para que copie y pegue en su pom.

Incluye las dependencias en tu paquete objetivo

Cuando haya creado su repositorio en proyecto, habrá resuelto un problema de distribución de las dependencias del proyecto con su origen, pero desde entonces el artefacto objetivo de su proyecto dependerá de jarras no publicadas, de modo que cuando lo instale a un repositorio, tendrá dependencias irresolubles.

Para vencer este problema, sugiero que incluya estas dependencias en su paquete de destino. Esto se puede hacer con el Complemento de ensamblaje o mejor con el Plugin OneJar. La documentación oficial de OneJar es fácil de entender.


557
2017-10-02 00:15



Solo para el código de descarte

establecer el alcance == sistema y simplemente crear un groupId, artifactId y versión

<dependency>
    <groupId>org.swinglabs</groupId>
    <artifactId>swingx</artifactId>
    <version>0.9.2</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/lib/swingx-0.9.3.jar</systemPath>
</dependency>

Nota: las dependencias del sistema no se copian en jar / guerra resultante
(ver Cómo incluir las dependencias del sistema en la guerra construida usando maven)


460
2017-12-12 21:21



Puede crear un repositorio local en su proyecto

Por ejemplo, si tiene libs carpeta en la estructura del proyecto

  • En libs carpeta debe crear una estructura de directorios como: /groupId/artifactId/version/artifactId-version.jar

  • En tu pom.xml debes registrar el repositorio

    <repository>
        <id>ProjectRepo</id>
        <name>ProjectRepo</name>
        <url>file://${project.basedir}/libs</url>
    </repository>
    
  • y agrega dependencia como de costumbre

    <dependency>
        <groupId>groupId</groupId>
        <artifactId>artifactId</artifactId>
        <version>version</version>
    </dependency>
    

Eso es todo.

Para información detallada: Cómo agregar bibliotecas externas en Maven


49
2017-10-05 13:01



Nota: cuando se utiliza el alcance del sistema (como se menciona en esta página), Maven necesita caminos absolutos.

Si sus archivos jar están debajo de la raíz de su proyecto, querrá prefijar los valores de SystemPath con $ {basedir}.


31
2018-01-08 21:58



Realmente debería tener un marco en su lugar a través de un repositorio e identificar sus dependencias por adelantado. Usar el alcance del sistema es un error común que las personas usan, porque "no les importa la gestión de la dependencia". El problema es que al hacer esto terminas con una construcción maven pervertida que no muestra al maven en condiciones normales. Sería mejor seguir un enfoque como esta.


14
2018-04-19 02:16



Esto es lo que he hecho, también funciona con el problema del paquete y funciona con el código desprotegido.

Creé una nueva carpeta en el proyecto en mi caso utilicé repo, pero siéntete libre de usar src/repo

En mi POM tuve una dependencia que no está en ningún repositorio maven público

<dependency>
    <groupId>com.dovetail</groupId>
    <artifactId>zoslog4j</artifactId>
    <version>1.0.1</version>
    <scope>runtime</scope>
</dependency>

Luego creé los siguientes directorios repo/com/dovetail/zoslog4j/1.0.1 y copió el archivo JAR en esa carpeta.

Creé el siguiente archivo POM para representar el archivo descargado (este paso es opcional, pero elimina una ADVERTENCIA) y ayuda al siguiente chico a averiguar dónde obtuve el archivo para comenzar.

<?xml version="1.0" encoding="UTF-8" ?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.dovetail</groupId>
    <artifactId>zoslog4j</artifactId>
    <packaging>jar</packaging>
    <version>1.0.1</version>
    <name>z/OS Log4J Appenders</name>
    <url>http://dovetail.com/downloads/misc/index.html</url>
    <description>Apache Log4j Appender for z/OS Logstreams, files, etc.</description>
</project>

Dos archivos opcionales que creo son las sumas de comprobación SHA1 para el POM y el JAR para eliminar las advertencias de suma de comprobación faltantes.

shasum -b < repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.jar \
          > repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.jar.sha1

shasum -b < repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.pom \
          > repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.pom.sha1

Finalmente agrego el siguiente fragmento a mi pom.xml que me permite referirme al repositorio local

<repositories>
    <repository>
        <id>project</id>
        <url>file:///${basedir}/repo</url>
    </repository>
</repositories>

12
2017-10-13 00:38



Maven install plugin tiene uso de línea de comandos para instalar un jar en el repositorio local, POM es opcional pero deberá especificar GroupId, ArtifactId, Version y Packaging (todo el material de POM).


11
2018-01-08 22:23



Así es como agregamos o instalamos un contenedor local

    <dependency>
        <groupId>org.example</groupId>
        <artifactId>iamajar</artifactId>
        <version>1.0</version>
        <scope>system</scope>
        <systemPath>${project.basedir}/lib/iamajar.jar</systemPath>
    </dependency>

di algunos groupId y artifactId predeterminados porque son obligatorios :)


10
2018-02-10 14:38



Utilizando <scope>system</scope> es una idea terrible por razones explicadas por otros, la instalación manual del archivo en el repositorio local hace que la construcción no sea reproducible, y el uso <url>file://${project.basedir}/repo</url> tampoco es una buena idea porque (1) eso puede no ser una forma bien formada file URL (por ejemplo, si el proyecto está desprotegido en un directorio con caracteres inusuales), (2) el resultado no se puede usar si el POM de este proyecto se usa como una dependencia del proyecto de otra persona.

Suponiendo que no está dispuesto a subir el artefacto a un repositorio público, la sugerencia de Simeon de un módulo auxiliar hace el trabajo. Pero ahora hay una manera más fácil ...

La recomendación

Utilizar no maven-jar-maven-plugin. Hace exactamente lo que estaba pidiendo, sin ninguno de los inconvenientes de los otros enfoques.


8
2018-05-10 01:47



Encontré otra manera de hacer esto, mire aquí desde Publicación de Heroku

Para resumir (lo siento por algunos copiar y pegar)

  • Crear un repo directorio debajo de su carpeta raíz:
tu proyecto
+ - pom.xml
+ - src
+ - repo
  • Ejecute esto para instalar el archivo jar en su directorio de repositorio local
mvn deploy: deploy-file -Durl = file: /// path / to / yourproject / repo / -Dfile = mylib-1.0.jar -DgroupId = com.example -DadifactId = mylib -Dpackaging = jar -Dversion = 1.0
  • Agrega esto tu pom.xml:
<repositories>
    <!--other repositories if any-->
    <repository>
        <id>project.local</id>
        <name>project</name>
        <url>file:${project.basedir}/repo</url>
    </repository>
</repositories>


<dependency>
    <groupId>com.example</groupId>
    <artifactId>mylib</artifactId>
    <version>1.0</version>  
</dependency>

8
2018-06-03 19:53