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.

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.

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 )

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

Nota: Al usar el alcance del sistema ( como se menciona en esta página ), Maven necesita rutas absolutas.

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

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>

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 .

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

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).

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.

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>

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

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>

El problema systemPathes que los frascos de las dependencias no se distribuirán a lo largo de sus artefactos como dependencias transitivas. Pruebe lo que he publicado aquí: ¿Es mejor Mavenize los archivos jar de su proyecto o ponerlos en WEB-INF / lib?

Luego declare las dependencias como de costumbre.

Y por favor lea la nota de pie de página.

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

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>
";

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.

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).

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

4. 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>

5. 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

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>

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

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.

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

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;

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();
    }
}