¿Puedo agregar jarras a maven 2 build classpath sin instalarlas?


700

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

Tengo un pom.xmlarchivo 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 un pom.xmlarchivo definido, por lo que en lugar de crear el pom.xmlarchivo para la biblioteca de terceros a mano e instalarlo, y agregar la dependencia a mi pom.xml, me gustaría decirle a Maven: "Además de mis dependencias definidas, incluya todos los frascos que también estén /lib".

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

Cualquier sugerencia sobre cómo hacer esto es muy apreciada. Aparte de eso, si hay una manera simple de apuntar a Maven a un /libdirectorio y crear fácilmente uno pom.xmlcon todos los archivos adjuntos asignados a una sola dependencia que luego podría nombrar / instalar y vincular de una sola vez, también sería suficiente.


Si está utilizando Netbeans, simplemente siga estos pasos: [¿Cómo instalo módulos en el repositorio de Maven usando Netbeans Embedded Maven?] [1] [1]: stackoverflow.com/a/339874/530153
Rajat Gupta

1
Quiero señalar que este enlace stackoverflow.com/a/339874/530153 parece funcionar para instalar los frascos de uno en uno.
Paul

Respuestas:


600

Problemas de enfoques populares

La mayoría de las respuestas que encontrará en Internet le sugerirán que instale la dependencia en su repositorio local o que especifique un alcance de "sistema" en pomy distribuya la dependencia con la fuente de su proyecto. Pero ambas soluciones son realmente defectuosas.

¿Por qué no debería aplicar el enfoque "Instalar en repositorio 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 deberá instalarse localmente en cada máquina que trabaje con ese proyecto, lo que no es mejor.

¿Por qué no debería aplicar el enfoque "Alcance del sistema"?

Los frascos de los que depende con el enfoque de "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 forma de resolver esa dependencia cuando se use. Creo que esa fue la razón por la cual el uso del alcance del sistema incluso quedó en desuso. De todos modos, no desea confiar en una función obsoleta.

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

Después de poner esto en tu 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.zMaven incluirá la siguiente ubicación dentro del directorio de su proyecto en su búsqueda de artefactos:

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

Para obtener más información sobre esto, puede leer esta publicación de blog .

Use Maven para instalar en el repositorio del proyecto

En lugar de crear esta estructura a mano, recomiendo usar un complemento Maven para instalar sus jarras como artefactos. Entonces, para instalar un artefacto en un repositorio dentro del proyecto en la repocarpeta, ejecute:

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

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

Un guión de ayuda

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

Incluya las dependencias en su paquete de destino

Cuando haya creado su repositorio en el proyecto, habrá resuelto el problema de distribuir las dependencias del proyecto con su fuente, pero desde entonces el artefacto objetivo de su proyecto dependerá de los frascos no publicados, así que cuando instale en un repositorio tendrá dependencias irresolubles.

Para superar este problema, sugiero incluir estas dependencias en su paquete de destino. Esto puede hacerlo con el complemento de ensamblaje o mejor con el complemento de OneJar . La documentación oficial sobre OneJar es fácil de entender.


3
Siempre supuse que podría crear un repositorio en el proyecto, finalmente lo confirmó, ¡genial!
albfan

19
Dos cosas a tener en cuenta: 1) Recomiendo usar "$ {project.baseUri} repo" en lugar de "file: // $ {project.basedir} / repo" para obtener una URL compatible con RFC también en Windows. 2) Si estructura su proyecto en submódulos, este enfoque parece fallar porque $ {project.baseUri} se resuelve en el subdirectorio del módulo. ¿Alguna idea de cómo resolver este problema?
Oliver Hanappi

8
Esto casi me llevó allí, pero el script de Nikita trató de ser demasiado inteligente con los archivos JAR mal nombrados que tenía. Así que hice una versión simplificada que no adivina el groupId: github.com/carchrae/install-to-project-repo
Tom Carchrae

3
¡Qué respuesta tan brillante! Hay 2 formas de hacer algo, la forma correcta y la forma en que funciona, ¡señor, lo hace de la manera correcta!
Panthro

1
aquí también encontrará información sobre cómo generar automáticamente el artefacto desde su archivo jar: devcenter.heroku.com/articles/local-maven-dependencies
Dirk

486

Solo para desechar código

establece el alcance == sistema y solo crea un groupId, artifactId y una 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 el jar / war resultante
(consulte Cómo incluir las dependencias del sistema en war construido con Maven )


44
Gracias, esto está muy cerca de lo que quiero. ¿Alguna forma de agregarlos todos como una sola entrada? Digamos que tengo / lib con 10 frascos, ¿puedo agregarlos todos de alguna manera, por ejemplo con /some/path/*.jar para systemPath? o todavía tengo que tratar a cada uno como una dependencia conocida? Aún así, muy cerca de lo que necesito, ¡gracias!

11
use un systemPath como este: "<systemPath> $ {basedir} /lib/BrowserLauncher2-1_3.jar </systemPath>" $ {basedir} apunta a la raíz de su proyecto.
Frederic Morin

44
Es mejor usar el proyecto. prefijo en su ruta así: <systemPath> $ {project.basedir} /lib/AwesomeLib.jar </systemPath>
Matthew McCullough

76
Si bien entiendo que esto es lo que pedía el OP, todavía quiero subrayar que el uso de un systemalcance es una práctica horrible que se desaconseja encarecidamente . Ver dependencia + ámbitos .
Pascal Thivent

66
@marioosh recuerda que la intención original de la pregunta era la experimentación rápida. Si desea hacer un paquete mvn, instale el jar en el repositorio.
Pirolítico

64

Puede crear un repositorio local en su proyecto

Por ejemplo, si tiene una libscarpeta en la estructura del proyecto

  • En la libscarpeta, 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 siempre

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

Eso es todo.

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


1
Tu respuesta es casi correcta. GroupId debe dividirse en varios subdirectorios.
Peter Fortuin

55
Por supuesto, si tiene un ID de grupo complejo como 'com.foo.bar', la estructura de su directorio debería ser /com/foo/bar/artifactId/version/artifactId-verion.jar
Dmytro Boichenko

¿Es esto significativamente diferente de la respuesta de un año antes ?
Joshua Taylor

En el último directorio, donde se encuentra el archivo jar, también debe agregar el archivo pom xml relacionado.
Federico


15

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

Creé una nueva carpeta en el proyecto en mi caso que usé repo, pero siéntase libre de usarsrc/repo

En mi POM tenía una dependencia que no está en ningún repositorio público de Maven

<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.1y 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 de dónde saqué el archivo para empezar.

<?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 verificación SHA1 para el POM y el JAR para eliminar las advertencias de suma de verificación que faltan.

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>

Hola, ¿pusiste los archivos pom en el repositorio local o al lado de tus archivos jar?
Peymankh

En la solución anterior estaba al lado de los archivos JAR. Eso sí, no me gusta la solución anterior porque es demasiado trabajo.
Arquímedes Trajano

Todavía prefiero la solución que publiqué
Archimedes Trajano

Me gusta este enfoque, aunque utilicé el complemento de instalación de Maven para automatizar la instalación del jar en el repositorio local.
Carl G

13

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


12

Así es como agregamos o instalamos un jar 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 :)


11

El complemento de instalación de Maven 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).


en realidad, lo que dice es que no tiene que crear un pom para la biblioteca que está importando en su repositorio local
Frederic Morin

55
-1, a veces solo quieres agregar un archivo jar sin la molestia de instalarlo.
Leonel

8

El uso <scope>system</scope>es una idea terrible por razones explicadas por otros, instalar el archivo manualmente en su repositorio local hace que la compilación sea irreproducible, y el uso <url>file://${project.basedir}/repo</url>tampoco es una buena idea porque (1) puede que no sea una fileURL bien formada (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 cargar el artefacto en un repositorio público, la sugerencia de Simeon de un módulo auxiliar hace el trabajo. Pero hay una manera más fácil ahora ...

La recomendación

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


También vi maven-external-dependency-plugin aunque non-maven-jar-maven-plugin parece más fácil de usar.
Jesse Glick

8

Encontré otra forma de hacer esto, mira aquí desde una publicación de Heroku

Para resumir (perdón por copiar y pegar)

  • Cree un repodirectorio debajo de su carpeta raíz:
tu proyecto
+ - pom.xml
+ - src
+ - repo
  • Ejecute esto para instalar el 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 -DartifactId = mylib -Dpackaging = jar -Dversion = 1.0
  • Agregue esto a su 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>

6

Después de tener una discusión muy larga con muchachos de CloudBees sobre el empaquetado adecuado de este tipo de JAR, hicieron una buena propuesta interesante para una solución:

Creación de un proyecto falso de Maven que adjunta un JAR preexistente como un artefacto principal, que se ejecuta en la instalación de POM: ejecución del archivo de instalación. Aquí hay un ejemplo de ese tipo de POM:

 <build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-install-plugin</artifactId>
            <version>2.3.1</version>
            <executions>
                <execution>
                    <id>image-util-id</id>
                    <phase>install</phase>
                    <goals>
                        <goal>install-file</goal>
                    </goals>
                    <configuration>
                        <file>${basedir}/file-you-want-to-include.jar</file>
                        <groupId>${project.groupId}</groupId>
                        <artifactId>${project.artifactId}</artifactId>
                        <version>${project.version}</version>
                        <packaging>jar</packaging>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Pero para implementarlo, se debe cambiar la estructura del proyecto existente. Primero, debe tener en cuenta que para cada tipo de JAR debe crearse un proyecto (módulo) falso de Maven diferente. Y debe crearse un proyecto Maven principal que incluya todos los submódulos que son: todos los contenedores JAR y el proyecto principal existente. La estructura podría ser:

proyecto raíz (este contiene el archivo POM principal incluye todos los submódulos con elemento XML de módulo ) (paquete POM)

Proyecto JAR 1 envoltorio Maven child (embalaje POM)

Proyecto JAR 2 wrapper Maven child (embalaje POM)

proyecto principal Maven child existente (WAR, JAR, EAR ... packaging)

Cuando el padre se ejecuta a través de mvn: install o mvn: el empaquetado es forzado y se ejecutarán submódulos. Esto podría ser un inconveniente aquí, ya que la estructura del proyecto debería cambiarse, pero ofrece una solución no estática al final


Solo una observación, pero no creo que necesite crear un nuevo POM para cada JAR que desee agregar. Debería ser suficiente crear un único POM para agregar todos los JAR siempre que tenga un bloque de ejecución para cada jar que desee agregar. Solo necesita asegurarse de que cada bloque tenga una identificación única. El resultado es un único módulo Maven que agregará todos los JAR al repositorio local. (¡Solo asegúrate de que las coordenadas de Maven no choquen con nada que ya esté allí o que se pueda agregar más tarde!)
Stormcloud

Héroe. Esto es EXACTAMENTE lo que quería. Buen chico. 2013 debe haber sido un buen año;)
ndtreviv

5

Lo que me parece más simple es simplemente configurar su complemento compilador-maven para incluir sus tarros personalizados. Este ejemplo cargará cualquier archivo jar en un directorio lib.

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <includes>
                    <include>lib/*.jar</include>
                </includes>
            </configuration>
        </plugin>

1
Si agrego este maven says nothing to complile!
Ravi Parekh

Dice all classes are up to date nothing to compileporque ya no buscará *.javamás. Puede agregarlos nuevamente usando <include>**/*.java</include>. Sin embargo, no hay éxito para mí en los frascos
Michael Laffargue

@Imiguelmh, ¿alguna razón por la que esto no funciona para los frascos?
kisna


3

Una extraña solución que encontré:

usando Eclipse

  • crear un proyecto java simple (no maven)
  • agregar una clase principal
  • agrega todos los frascos al classpath
  • exportar JAR ejecutable (es importante, porque no hay otra forma de hacerlo aquí)
  • seleccione Extraer bibliotecas necesarias en JAR generado
  • decidir los problemas de licencia
  • tadammm ... instala el jar generado en tu m2repo
  • agregue esta dependencia única a sus otros proyectos.

aclamaciones, Balint


3

Si desea una solución rápida y sucia, puede hacer lo siguiente (aunque no lo recomiendo para nada, excepto para proyectos de prueba, Maven se quejará por completo de que esto no es apropiado).

Agregue una entrada de dependencia para cada archivo jar que necesite, preferiblemente con un script perl o algo similar y cópielo / péguelo en su archivo pom.

#! /usr/bin/perl

foreach my $n (@ARGV) {

    $n=~s@.*/@@;

    print "<dependency>
    <groupId>local.dummy</groupId>
    <artifactId>$n</artifactId>
    <version>0.0.1</version>
    <scope>system</scope>
    <systemPath>\${project.basedir}/lib/$n</systemPath>
</dependency>
";

Sí, esto es exactamente lo que estaba buscando. Una forma de impulsarlo para el código de prueba de investigación. Nada sofisticado. Sí, sé que eso es lo que todos dicen :) Las diversas soluciones de complementos de Maven parecen ser excesivas para mis propósitos. Tengo algunos tarros que me dieron como librerías de terceros con un archivo pom. Quiero que se compile / ejecute rápidamente. Esta solución que adapté trivialmente a Python funcionó de maravilla para mí. Cortado y pegado en mi pom.
Paul

3

Una solución por lotes rápida y sucia (basada en la respuesta de Alex):

libs.bat

@ECHO OFF
FOR %%I IN (*.jar) DO (
echo ^<dependency^>
echo ^<groupId^>local.dummy^</groupId^>
echo ^<artifactId^>%%I^</artifactId^>
echo ^<version^>0.0.1^</version^>
echo ^<scope^>system^</scope^>
echo ^<systemPath^>${project.basedir}/lib/%%I^</systemPath^>
echo ^</dependency^>
)

Ejecutarlo así: libs.bat > libs.txt. Luego abra libs.txty copie su contenido como dependencias.

En mi caso, solo necesitaba las bibliotecas para compilar mi código, y esta solución fue la mejor para ese propósito.


2

Aunque no se ajusta exactamente a su problema, dejaré esto aquí. Mis requisitos fueron:

  1. Los frascos que no se pueden encontrar en un repositorio Maven en línea deben estar en el SVN.
  2. Si un desarrollador agrega otra biblioteca, los otros desarrolladores no deberían molestarse en instalarlos manualmente.
  3. El IDE (NetBeans en mi caso) debería poder encontrar las fuentes y los javadocs para proporcionar autocompletado y ayuda.

Hablemos primero de (3): simplemente tener los frascos en una carpeta y fusionarlos de alguna manera en el frasco final no funcionará aquí, ya que el IDE no lo entenderá. Esto significa que todas las bibliotecas deben instalarse correctamente. Sin embargo, no quiero que todos lo instalen usando "mvn install-file".

En mi proyecto necesitaba un metawidget. Aquí vamos:

  1. Crea un nuevo proyecto maven (nómbralo "shared-libs" o algo así).
  2. Descarga metawidget y extrae el zip en src / main / lib.
  3. La carpeta doc / api contiene los javadocs. Cree un zip del contenido (doc / api / api.zip).
  4. Modifica el pom así
  5. Construya el proyecto y se instalará la biblioteca.
  6. Agregue la biblioteca como dependencia a su proyecto o (si agregó la dependencia en el proyecto shared-libs) agregue shared-libs como dependencia para obtener todas las bibliotecas a la vez.

Cada vez que tenga una nueva biblioteca, simplemente agregue una nueva ejecución y pídales a todos que vuelvan a construir el proyecto (puede mejorar este proceso con jerarquías de proyecto).


Es posible que desee comprobar Maven: agregue una dependencia a un jar por ruta relativa (que es en mi humilde opinión una mejor alternativa).
Pascal Thivent

Es mejor si puede asegurarse de que el repositorio local siempre tenga la misma ruta relativa al proyecto. Si tengo muchos proyectos (o diferentes sucursales) en diferentes ubicaciones, esto no funcionará.
Cefalópodo

Mi respuesta tiene una manera de decirle a pom.xml sobre un frasco dentro de su proyecto. ¿Por qué no simplemente hacer eso y señalarlo en frascos en $ {basedir} / lib?
Ed Brannin

1
@Ed Debido a que el alcance del sistema no es para eso en absoluto, las dependencias del sistema tienen muchos efectos secundarios. Esta es una práctica horrible que debería estar totalmente prohibida.
Pascal Thivent

2

Para instalar el jar de terceros que no está en el repositorio de maven, use maven-install-plugin.

A continuación hay pasos:

  1. Descargue el archivo jar manualmente desde la fuente (sitio web)
  2. Crea una carpeta y coloca tu archivo jar en ella
  3. Ejecute el siguiente comando para instalar el jar de terceros en su repositorio local de Maven

mvn install: install-file -Dfile = -DgroupId = -DartifactId = -Dversion = -Dpackaging =

A continuación se muestra el que usé para simonsite log4j

mvn install: install-file -Dfile = / Users / athanka / git / MyProject / repo / log4j-rolling-appender.jar -DgroupId = uk.org.simonsite -DartifactId = log4j-rolling-appender -Dversion = 20150607-2059 - Dpackaging = jar

  1. En pom.xml incluya la dependencia como se muestra a continuación

      <dependency> 
            <groupId>uk.org.simonsite</groupId>
            <artifactId>log4j-rolling-appender</artifactId>
            <version>20150607-2059</version> 
      </dependency>
  2. Ejecute el comando mvn clean install para crear su empaque

A continuación se muestra el enlace de referencia:

https://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html


Esta es una respuesta límite de solo enlace . Debe ampliar su respuesta para incluir tanta información aquí, y usar el enlace solo como referencia.
Goodbye StackExchange el

2

Para aquellos que no encontraron una buena respuesta aquí, esto es lo que estamos haciendo para obtener un frasco con todas las dependencias necesarias. Esta respuesta ( https://stackoverflow.com/a/7623805/1084306 ) menciona el uso del complemento Maven Assembly pero en realidad no da un ejemplo en la respuesta. Y si no lee hasta el final de la respuesta (es bastante larga), puede que se la pierda. Agregar lo siguiente a su pom.xml generarátarget/${PROJECT_NAME}-${VERSION}-jar-with-dependencies.jar

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-assembly-plugin</artifactId>
            <version>2.4.1</version>
            <configuration>
                <!-- get all project dependencies -->
                <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
                <!-- MainClass in mainfest make a executable jar -->
                <archive>
                  <manifest>
                    <mainClass>my.package.mainclass</mainClass>
                  </manifest>
                </archive>

            </configuration>
            <executions>
              <execution>
                <id>make-assembly</id>
                <!-- bind to the packaging phase -->
                <phase>package</phase> 
                <goals>
                    <goal>single</goal>
                </goals>
              </execution>
            </executions>
        </plugin>

1

Aludí a algún código de Python en un comentario a la respuesta de @alex lehmann's, así que lo publico aquí.

def AddJars(jarList):
  s1 = ''
  for elem in jarList:
   s1+= """
     <dependency>
        <groupId>local.dummy</groupId>
        <artifactId>%s</artifactId>
        <version>0.0.1</version>
        <scope>system</scope>
        <systemPath>${project.basedir}/manual_jars/%s</systemPath>
     </dependency>\n"""%(elem, elem)
  return s1

0

Esto no responde cómo agregarlos a su POM, y puede ser obvio, pero ¿solo agregaría el directorio lib a su trabajo classpath? Sé que eso es lo que hago cuando necesito un jar externo que no quiero agregar a mis repositorios de Maven.

Espero que esto ayude.


1
Esto es lo que estaba haciendo, y funciona, pero también contamina el camino de clase global, y estoy tratando de alejarme de él. ¡Gracias!

@purple Exactamente, ¿cómo hiciste eso?
TheRealChx101

0

Lo que funciona en nuestro proyecto es lo que escribió Arquímedes Trajano, pero teníamos en nuestro .m2 / settings.xml algo como esto:

 <mirror>
  <id>nexus</id>
  <mirrorOf>*</mirrorOf>
  <url>http://url_to_our_repository</url>
 </mirror>

y * debe cambiarse a central. Entonces, si su respuesta no funciona para usted, debe verificar su settings.xml


0

Solo quería una solución rápida y sucia ... No pude ejecutar el script desde Nikita Volkov: error de sintaxis + requiere un formato estricto para los nombres de jar.

Hice este script Perl que funciona con cualquier formato para los nombres de archivo jar, y genera las dependencias en un xml para que pueda copiarse y pegarse directamente en un pom.

Si desea usarlo, asegúrese de comprender lo que está haciendo el script, es posible que deba cambiar el lib carpeta y el valor de la groupIdo artifactId...

#!/usr/bin/perl

use strict;
use warnings;

open(my $fh, '>', 'dependencies.xml') or die "Could not open file 'dependencies.xml' $!";
foreach my $file (glob("lib/*.jar")) {
    print "$file\n";
    my $groupId = "my.mess";
    my $artifactId = "";
    my $version = "0.1-SNAPSHOT";
    if ($file =~ /\/([^\/]*?)(-([0-9v\._]*))?\.jar$/) {
        $artifactId = $1;
        if (defined($3)) {
            $version = $3;
        }
        `mvn install:install-file -Dfile=$file -DgroupId=$groupId -DartifactId=$artifactId -Dversion=$version -Dpackaging=jar`;
        print $fh "<dependency>\n\t<groupId>$groupId</groupId>\n\t<artifactId>$artifactId</artifactId>\n\t<version>$version</version>\n</dependency>\n";
        print " => $groupId:$artifactId:$version\n";
    } else {
        print "##### BEUH...\n";
    }
}
close $fh;

0

La solución para el enfoque del alcance = 'sistema' en Java:

public static void main(String[] args) {
        String filepath = "/Users/Downloads/lib/";
        try (Stream<Path> walk = Files.walk(Paths.get(filepath))) {

        List<String> result = walk.filter(Files::isRegularFile)
                .map(x -> x.toString()).collect(Collectors.toList());

                String indentation = "    ";
                for (String s : result) {
                    System.out.println(indentation + indentation + "<dependency>");
                    System.out.println(indentation + indentation + indentation + "<groupId>"
                            + s.replace(filepath, "").replace(".jar", "")
                            + "</groupId>");
                    System.out.println(indentation + indentation + indentation + "<artifactId>"
                            + s.replace(filepath, "").replace(".jar", "")
                            + "</artifactId>");
                    System.out.println(indentation + indentation + indentation + "<version>"
                            + s.replace(filepath, "").replace(".jar", "")
                            + "</version>");
                    System.out.println(indentation + indentation + indentation + "<scope>system</scope>");
                    System.out.println(indentation + indentation + indentation + "<systemPath>" + s + "</systemPath>");
                    System.out.println(indentation + indentation + "</dependency>");
                }

    } catch (IOException e) {
        e.printStackTrace();
    }
}
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.