java español - Tener un tarro de terceros incluido en el bote sombreado de Maven sin agregarlo al repositorio local




tutorial jar (4)

Usé <recursos> para incluir mi lib con todos los frascos. es decir:

<build>
    <resources>
        <resource>
            <directory>${project.basedir}</directory>
            <includes>
                <include>lib/*.jar</include>
            </includes>
        </resource>
    </resources>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-shade-plugin</artifactId>
            <version>2.3</version>
            <configuration>
                <createDependencyReducedPom>false</createDependencyReducedPom>
            </configuration>
            <executions>
                <execution>
                    <phase>package</phase>
                    <goals>
                        <goal>shade</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Ya encontré una respuesta aquí en sobre cómo incluir un JAR de terceros en un proyecto sin instalarlo en un "repositorio local":

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

Pero, cuando uso Maven Shade Plugin para crear un JAR que también incluye todas las dependencias del proyecto, el JAR de terceros no se incluye automáticamente.

¿Cómo puedo hacer que Maven Shade Plugin agregue un JAR de este tipo en el JAR sombreado?

Según la respuesta obtenida, lo hice funcionar. Lo que hice fue agregar este fragmento al principio de mi pom.xml:

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

Luego agregué una dependencia para mi proyecto, también a pom.xml:

<dependencies>
  <dependency>
    <groupId>dummy</groupId>
    <artifactId>dummy</artifactId>
    <version>0.0.0</version>
    <scope>compile</scope>
  </dependency>
</dependencies>

Y luego ejecuté una línea de comando para agregar un paquete a 'repo':

mvn org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file
    -Dfile=<my-jar>.jar -DgroupId=dummy -DartifactId=dummy
    -Dversion=0.0.0 -Dpackaging=jar -DlocalRepositoryPath=`pwd`/repo/

(No estoy seguro de si la ruta de repos debe ser una ruta completa, pero no quería correr riesgos).

El contenido del subdirectorio repo ahora es:

repo/dummy/dummy/0.0.0/dummy-0.0.0.jar
repo/dummy/dummy/0.0.0/dummy-0.0.0.pom
repo/dummy/dummy/maven-metadata-local.xml

Ahora puedo verificar esto en el control de la versión, y no tengo dependencias locales o remotas.



Pero, cuando uso Maven Shade Plugin para crear un JAR que también incluye todas las dependencias del proyecto, el JAR de terceros no se incluye automáticamente.

Sí, porque se supone que las dependencias del ámbito del system siempre están presentes (esto es exactamente de lo system se trata el alcance del system ), por lo que no se incluirán. La gente en realidad no entiende qué son las dependencias del alcance del system , solo siguen abusando de ellas (sí, esto es abuso), y luego obtiene efectos secundarios y se pregunta por qué (como Brian señaló en su answer ).

Ya escribí many , many , many veces sobre esto aquí en SO y en el 99% de los casos, system deben evitar las dependencias del ámbito del system . Y repetiré lo que la mini guía de Dependency Scopes dice una vez más:

  • system : esta dependencia es necesaria en alguna fase del ciclo de vida de su proyecto, pero es específica del sistema. Se desaconseja el uso de este alcance: se considera un tipo de función "avanzada" y solo se debe utilizar cuando se entiendan todas las ramificaciones de su uso, que puede ser extremadamente difícil si no imposible de cuantificar. Este alcance, por definición, hace que su construcción no sea portátil. Puede ser necesario en ciertos casos de borde. El alcance del sistema incluye el elemento <systemPath> que apunta a la ubicación física de esta dependencia en la máquina local. Por lo tanto, se usa para referirse a algún artefacto que se espera que esté presente en la máquina local dada y no en un repositorio; y cuya ruta puede variar de máquina a máquina. El elemento systemPath puede hacer referencia a variables de entorno en su ruta: ${JAVA_HOME} por ejemplo.

Entonces, en lugar de usar el alcance del system , ya sea:

  • Agregue sus bibliotecas a su repositorio local a través de install:install-file . Esta es una manera rápida y sucia de hacer que las cosas funcionen, podría ser una opción si estás solo pero hace que tu compilación no sea portátil.
  • Instale y ejecute un "repositorio empresarial" como Nexus, Archiva o Artifactory y agregue sus bibliotecas mediante deploy:deploy-file . Este es el escenario ideal .
  • Configure un repositorio basado en archivos como se describe en esta respuesta anterior y coloque sus bibliotecas allí. Este es el mejor compromiso si no tiene un repositorio corporativo, pero necesita trabajar en equipo y no quiere sacrificar la portabilidad.

Por favor, deja de usar el alcance del system .


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

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

y el * debe cambiarse a central. Entonces, si su respuesta no funciona para usted, debe revisar su configuración.xml





java maven-2