Los artefactos de las dependencias se pueden excluir declarando un <exclusions>elemento dentro de un <dependency>Pero en este caso es necesario excluir un artefacto heredado de un proyecto principal. A continuación, se muestra un extracto del POM en discusión:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>test</groupId>
  <artifactId>jruby</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <parent>
        <artifactId>base</artifactId>
        <groupId>es.uniovi.innova</groupId>
        <version>1.0.0</version>
    </parent>

    <dependencies>      
        <dependency>
            <groupId>com.liferay.portal</groupId>
            <artifactId>ALL-DEPS</artifactId>
            <version>1.0</version>
            <scope>provided</scope>
            <type>pom</type>
        </dependency>
    </dependencies>
</project>

baseartefacto, depende javax.mail:mail-1.4.jary ALL-DEPSdepende de otra versión de la misma biblioteca. Debido al hecho de que mail.jardesde ALL-DEPSexiste en el entorno de ejecución, aunque no se exporta, choca con el mail.jarque existe en el padre, que tiene el alcance compile.

Una solución podría ser eliminar mail.jar del POM principal, pero la mayoría de los proyectos que heredan la base la necesitan (como es una dependencia transtiva para log4j). Entonces, lo que me gustaría hacer es simplemente excluir la biblioteca principal del proyecto secundario , ya que se podría hacer si basefuera una dependencia y no el pom principal:

...
    <dependency>
        <artifactId>base</artifactId>
        <groupId>es.uniovi.innova</groupId>
        <version>1.0.0</version>
        <type>pom<type>
        <exclusions>
          <exclusion>
             <groupId>javax.mail</groupId>
             <artifactId>mail</artifactId>
          </exclusion>
        </exclusions>
    </dependency>
...

Algunas ideas:

1. Tal vez simplemente no podría heredar del padre en ese caso (y declarar una dependencia basecon la exclusión). No es útil si tiene muchas cosas en el pom principal.

2. Otra cosa para probar sería declarar el mailartefacto con la versión requerida por ALL-DEPSdebajo del dependencyManagementen el pom principal para forzar la convergencia (aunque no estoy seguro de que esto resuelva el problema de alcance).

<dependencyManagement>
  <dependencies>
    <dependency>    
      <groupId>javax.mail</groupId>
      <artifactId>mail</artifactId>
      <version>???</version><!-- put the "right" version here -->
    </dependency>
  </dependencies>
</dependencyManagement>

1. O puede excluir la maildependencia de log4j si no está utilizando las funciones que dependen de él (y esto es lo que haría):

<dependency>
  <groupId>log4j</groupId>
  <artifactId>log4j</artifactId>
  <version>1.2.15</version>
  <scope>provided</scope>
  <exclusions>
    <exclusion>
      <groupId>javax.mail</groupId>
      <artifactId>mail</artifactId>
    </exclusion>
    <exclusion>
      <groupId>javax.jms</groupId>
      <artifactId>jms</artifactId>
    </exclusion>
    <exclusion>
      <groupId>com.sun.jdmk</groupId>
      <artifactId>jmxtools</artifactId>
    </exclusion>
    <exclusion>
      <groupId>com.sun.jmx</groupId>
      <artifactId>jmxri</artifactId>
    </exclusion>
  </exclusions>
</dependency>

1. O puede volver a la versión 1.2.14 de log4j en lugar de la versión hereje 1.2.15 (¿por qué no marcaron las dependencias anteriores como opcionales ?).

Puede agrupar sus dependencias dentro de un proyecto diferente con un paquete pomcomo se describe en las Mejores prácticas de Sonatypes :

<project>
    <modelVersion>4.0.0</modelVersion>
    <artifactId>base-dependencies</artifactId>
    <groupId>es.uniovi.innova</groupId>
    <version>1.0.0</version>
    <packaging>pom</packaging>
    <dependencies>
        <dependency>
            <groupId>javax.mail</groupId>
            <artifactId>mail</artifactId>
            <version>1.4</version>
        </dependency>
    </dependencies>
</project>

y haga referencia a ellos desde su parent-pom (observe la dependencia <type>pom</type>):

<project>
    <modelVersion>4.0.0</modelVersion>
    <artifactId>base</artifactId>
    <groupId>es.uniovi.innova</groupId>
    <version>1.0.0</version>
    <packaging>pom</packaging>
    <dependencies>
        <dependency>
            <artifactId>base-dependencies</artifactId>
            <groupId>es.uniovi.innova</groupId>
            <version>1.0.0</version>
            <type>pom</type>
        </dependency>
    </dependencies>
</project>

Su proyecto hijo hereda este pom principal como antes. Pero ahora, la dependencia de correo se puede excluir en el proyecto hijo dentro del dependencyManagementbloque:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>test</groupId>
    <artifactId>jruby</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <parent>
        <artifactId>base</artifactId>
        <groupId>es.uniovi.innova</groupId>
        <version>1.0.0</version>
    </parent>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <artifactId>base-dependencies</artifactId>
                <groupId>es.uniovi.innova</groupId>
                <version>1.0.0</version>
                <exclusions>
                    <exclusion>
                        <groupId>javax.mail</groupId>
                        <artifactId>mail</artifactId>
                    </exclusion>
                </exclusions>
            </dependency>
        </dependencies>
    </dependencyManagement>
</project>

No uses un pom principal

Esto puede sonar extremo, pero de la misma manera que el "infierno de la herencia" es una razón por la que algunas personas dan la espalda a la Programación Orientada a Objetos (o prefieren la composición a la herencia ), eliminan el <parent>bloque problemático y copian y pegan lo <dependencies>que necesiten (si su equipo le da esta libertad).

Se debe ignorar la suposición de que la división de poms en padres e hijos para "reutilizarlos" y "evitar la redundancia" debe ser ignorada y usted debe atender sus necesidades inmediatas primero (la cura es peor que la enfermedad). Además, la redundancia tiene sus ventajas, a saber, la independencia de los cambios externos (es decir, la estabilidad).

Esto es más fácil de lo que parece si genera el pom efectivo (eclipse lo proporciona pero puede generarlo desde la línea de comandos con mvn help:effective).

Ejemplo

Quiero usarlo logbackcomo mi enlace slf4j, pero mi pom principal incluye la log4jdependencia. No quiero ir y tener que empujar la dependencia de los otros niños a log4j en sus propios pom.xmlarchivos para que el mío no esté obstruido.

Redefina la dependencia (en el pom hijo) con el scopesistema apuntando a un frasco vacío:

<dependency>
    <groupId>dependency.coming</groupId>
    <artifactId>from.parent</artifactId>
    <version>0</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/empty.jar</systemPath>
</dependency>

El frasco puede contener solo un archivo vacío:

touch empty.txt
jar cvf empty.txt

¿Ha intentado declarar explícitamente la versión de mail.jar que desea? La resolución de dependencia de Maven debería usar esto para la resolución de dependencia sobre todas las demás versiones.

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>test</groupId>
  <artifactId>jruby</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <parent>
        <artifactId>base</artifactId>
        <groupId>es.uniovi.innova</groupId>
        <version>1.0.0</version>
    </parent>
    <dependencies>          
        <dependency>
            <groupId>javax.mail</groupId>
            <artifactId>mail</artifactId>
            <version>VERSION-#</version>
            <scope>provided</scope>
        </dependency> 
        <dependency>
            <groupId>com.liferay.portal</groupId>
            <artifactId>ALL-DEPS</artifactId>
            <version>1.0</version>
            <scope>provided</scope>
            <type>pom</type>
        </dependency>
    </dependencies>
</project>

La mejor opción es hacer que las dependencias que no siempre desea heredar sean intransitivas.

Puede hacer esto marcándolos en el pom principal con el alcance proporcionado.

Si aún desea que el padre administre las versiones de estos departamentos, puede usar la <dependencyManagement>etiqueta para configurar las versiones que desee sin heredarlas explícitamente o pasar esa herencia a los hijos.

Cuando llama a un paquete pero no desea algunas de sus dependencias, puede hacer algo como esto (en este caso, no quería que se agregara el antiguo log4j porque necesitaba usar el más nuevo):

<dependency>
  <groupId>package</groupId>
  <artifactId>package-pk</artifactId>
  <version>${package-pk.version}</version>

  <exclusions>
    <exclusion>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-core</artifactId>
    </exclusion>
    <exclusion>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-api</artifactId>
    </exclusion>
  </exclusions>
</dependency>

<!-- LOG4J -->
<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-core</artifactId>
  <version>2.5</version>
</dependency>
<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-api</artifactId>
  <version>2.5</version>
</dependency>

Esto funciona para mí ... pero soy bastante nuevo en java / maven, por lo que tal vez no sea óptimo.

Realmente necesitaba hacer esta cosa sucia ... Así es como

Redefiní esas dependencias con alcance test. Scope providedno funcionó para mí.

Usamos el complemento Spring Boot para construir fat jar. Tenemos un módulo común que define bibliotecas comunes, por ejemplo Springfox swagger-2. Mi superservicio debe tener un padre en común (no quiere hacerlo, ¡pero las reglas de la compañía obligan!)

Entonces mi padre o los comunes tienen pom.

<dependencyManagement>

    <!- I do not need Springfox in one child but in others ->

    <dependencies>
        <dependency>
            <groupId>io.springfox</groupId>
            <artifactId>springfox-swagger2</artifactId>
            <version>${swagger.version}</version>
            <exclusions>
                <exclusion>
                    <groupId>com.google.guava</groupId>
                    <artifactId>guava</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>io.springfox</groupId>
            <artifactId>springfox-swagger-ui</artifactId>
            <version>${swagger.version}</version>
        </dependency>
        <dependency>
            <groupId>io.springfox</groupId>
            <artifactId>springfox-bean-validators</artifactId>
            <version>${swagger.version}</version>
        </dependency>

       <!- All services need them ->
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>${junit.version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.poi</groupId>
            <artifactId>poi-ooxml</artifactId>
            <version>${apache.poi.version}</version>
        </dependency>
    </dependencies>
</dependencyManagement>

Y mi pom de súper servicio .

<name>super-service</name>
<parent>
    <groupId>com.company</groupId>
    <artifactId>common</artifactId>
    <version>1</version>
</parent>

<dependencies>

    <!- I don't need them ->

    <dependency>
        <groupId>io.springfox</groupId>
        <artifactId>springfox-swagger2</artifactId>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>io.springfox</groupId>
        <artifactId>springfox-bean-validators</artifactId>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>io.springfox</groupId>
        <artifactId>springfox-core</artifactId>
        <version>2.8.0</version>
        <scope>test</scope>
    </dependency>

    <!- Required dependencies ->

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
     <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
    </dependency>
    <dependency>
        <groupId>org.apache.poi</groupId>
        <artifactId>poi-ooxml</artifactId>
    </dependency>
</dependencies>

Este es el tamaño del artefacto de grasa final.

82.3 MB (86,351,753 bytes) - redefined dependency with scope test
86.1 MB (90,335,466 bytes) - redefined dependency with scope provided
86.1 MB (90,335,489 bytes) - without exclusion

También vale la pena mencionar esta respuesta: quería hacerlo, pero soy vago ... https://stackoverflow.com/a/48103554/4587961

Podemos agregar el pom principal como una dependencia con el tipo pom y excluirlo. Porque de todos modos se descarga parent pom. Esto funcionó para mi

<dependency>
  <groupId>com.abc.boot</groupId>
  <artifactId>abc-boot-starter-parent</artifactId>
  <version>2.1.5.RELEASE</version>
  <type>pom</type>
  <exclusions>
    <exclusion>
      <groupId>com.google.code.gson</groupId>
      <artifactId>gson</artifactId>
    </exclusion>
  </exclusions>   
</dependency>