2012-04-05 10 views
5

Estoy usando Maven 3 para construir una aplicación Java con 3 niveles: server, ejb y ui. El proyecto EJB depende del proyecto Servidor, y el proyecto UI solo depende de EJB, y proporciona una exclusión para la dependencia transitiva del Servidor.Maven Build different to Dependency Tree

Cuando el proyecto de IU se construye como una guerra, la dependencia del Servidor se incluye a pesar de que no aparece en la dependencia: comando de árbol.

Aquí está la salida correspondiente de funcionamiento mvn dependency:tree

**project.name:UI:war:1.0 SNAPSHOT** 
+- project.name:Common:jar:1.0 SNAPSHOT:compile 
| + org_common:_lib:jar:16.0.006:compile 
| | +- log4j:log4j:jar:1.2.16:compile 
| | \- commons configuration:commons configuration:jar:1.6:compile 
| |  +- commons lang:commons lang:jar:2.4:compile 
| |  +- commons digester:commons digester:jar:1.8:compile 
| |  \- commons beanutils:commons beanutils core:jar:1.8.0:compile 
| +- org_common:_security_lib:jar:16.0.006:compile 
| \- org.springframework:spring:jar:2.0:compile 
+- **project.name:EJB:ejb client:client:1.0 SNAPSHOT:compile** 
| \- com.ibm.websphere.appserver:j2ee:jar:7.0.0.9:compile 
+- org_common:_uicomponent:jar:16.0.006:compile 

Y aquí es el árbol de dependencias de salida desde cuando se ejecuta mvn clean install -X

**project.name:UI:war:1.0 SNAPSHOT** 
+- project.name:Common:jar:1.0 SNAPSHOT:compile 
| + org_common:_lib:jar:16.0.006:compile 
| | +- log4j:log4j:jar:1.2.16:compile 
| | \- commons configuration:commons configuration:jar:1.6:compile 
| |  +- commons lang:commons lang:jar:2.4:compile 
| |  +- commons digester:commons digester:jar:1.8:compile 
| |  \- commons beanutils:commons beanutils core:jar:1.8.0:compile 
| +- org_common:_security_lib:jar:16.0.006:compile 
| \- org.springframework:spring:jar:2.0:compile 
+- **project.name:EJB:ejb client:client:1.0 SNAPSHOT:compile** 
| +- **project.name:Server:jar:1.0 SNAPSHOT:compile** 
| | +- javassist:javassist:jar:3.4.GA:compile 
| | +- project.filestore:filestore_client:jar:7.0.003:compile 
| | +- com.ibm.db2:db2jcc:jar:9.7.fp1.aix64.s091114:compile 
| | +- com.ibm.db2:db2java:jar:9.7.fp1.aix64.s091114:compile 
| | +- com.ibm.db2:db2jcc_license_cu:jar:9.7.fp1.aix64.s091114:compile 
| \- com.ibm.websphere.appserver:j2ee:jar:7.0.0.9:compile 
+- org_common:_uicomponent:jar:16.0.006:compile 

La dependencia de los servidores es la única diferencia entre los dos árboles. ¿No deberían estas dos salidas ser siempre las mismas? ¿Qué podría causar que se incluya una biblioteca que no aparece en la dependencia: árbol?

El POM matriz define los módulos como:

<modules> 
    <module>Server</module> 
    <module>EJB</module> 
    <module>UI</module> 
</modules> 

La dependencia que figuran en el POM EJB es:

<dependencies> 
     <dependency> 
      <groupId>project.name</groupId> 
      <artifactId>Server</artifactId> 
      <version>${project.version}</version> 
     </dependency> 
    </dependencies> 

La dependencia en la interfaz de usuario es:

<dependencies> 
     <dependency> 
      <groupId>project.name</groupId> 
      <artifactId>EJB</artifactId> 
      <version>${project.version}</version> 
      <type>ejb-client</type> 
      <exclusions> 
       <exclusion> 
        <groupId>project.name</groupId> 
        <artifactId>Server</artifactId> 
       </exclusion> 
      </exclusions> 
     </dependency> 
</dependencies> 

I Soy consciente de que puedo excluir explícitamente el jar Servidor de ser incluido en el WAR, pero preferiría arreglar el actua l problema.

+0

Si la IU depende de EJB y EJB depende del Servidor, la IU depende del Servidor. Por lo tanto, puede excluir a EJB con sus dependencias transitivas de 'WEB-INF/lib' estableciendo su alcance en' provided', o los empaqueta a todos en war.Que yo sepa, no hay forma de incluir solo artefactos de base sin sus dependencias transitivas en guerra. –

+0

¿Está utilizando el complemento de dependencia más reciente (2.4)? – khmarbaise

+0

@AndrewLogvinov Es por eso que tengo la exclusión en el servidor cuando el proyecto EJB se agrega como una dependencia a la interfaz de usuario. El nivel EJB es especial en maven; está dividido en tarros de cliente y servidor; el tarro de cliente del que depende la interfaz de usuario no tiene una dependencia en el servidor. Si la dependencia transitiva se excluye explícitamente, ¿por qué debería incluirse? –

Respuesta

1

Como nos dimos cuenta en los comentarios, la fuente del problema era con errores Maven 3.0.3. La versión 3.0.4 ha resuelto el problema.

Mi comentario no:

Qué exacta Maven versión utiliza? Si no es 3.0.4, pruébalo y di si ayuda. He encontrado realmente, REALMENTE cosas desagradables al usar lanzamientos anteriores de Maven 3, principalmente con 3.0.2.

2

Tiene razón en que la salida debe ser la misma en ambos casos. Sin embargo, Maven 3 pasó a utilizar Aether para la resolución de dependencias, pero a partir de ahora la dependencia: tree usa el antiguo mecanismo de resolución de dependencia y por eso la diferencia. Vea el siguiente enlace para más detalles.

https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-DependencyResolution

Debido a esta razón, sólo debe confiar en la salida del MVN instalación limpia -X para la gestión de la dependencia.

Editar

Desde la versión 2.5 del Maven Dependencia Plugin, dependency:tree también utiliza Éter (véase la bug report, y el release notes)

+0

Eso explica por qué los dos árboles son diferentes. ¿Alguna idea de cómo corregir el problema de la dependencia transitiva? –

Cuestiones relacionadas