2012-07-10 10 views
6

Tenemos una solución en la que nuestros proyectos de IU incluyen muchos servicios empresariales mediante el uso de las dependencias de los clientes EJB. El problema con esto en Maven es que aunque el cliente .jar generalmente contiene alrededor de 1-2 clases, traen consigo la pila de dependencia completa de la aplicación de servicio completa. Esto puede ponerse un poco feo, cuando los archivos .ear comienzan a crecer hasta 50-100Mb a pop y, de vez en cuando hay molestos errores gracias a dependencias irrelevantes que se abren paso a escondidas en la aplicación de la interfaz de usuario.Exclusión de dependencia de generación Maven ejb-client

Por supuesto, siempre podemos excluir las dependencias en el extremo del cliente, pero luego tenemos que escribir el mismo grupo de líneas para cada proyecto de cliente utilizando esos servicios y eso es una gran cantidad de repeticiones innecesarias. Además, la gente presenta los mensajes de error más extraños y utiliza mucho tiempo para rastrearlos antes de recordar mencionar que incluyeron algunos contenedores de clientes y no verificaron las dependencias adicionales que traía a la ecuación.

Ejemplo:

 <dependency> 
      <groupId>fi.path.to.service</groupId> 
      <artifactId>customermanagement-common</artifactId> 
      <version>2.6</version> 
     </dependency> 
     <dependency> 
      <groupId>fi.path.to.service</groupId> 
      <artifactId>customermanagement-service</artifactId> 
      <classifier>client</classifier> 
      <exclusions> 
       <exclusion> 
        <groupId>fi.path.to.dependency</groupId> 
        <artifactId>internal-dependency-#1</artifactId> 
       </exclusion> 
       <exclusion> 
        <groupId>org.codehaus.castor</groupId> 
        <artifactId>castor</artifactId> 
       </exclusion> 
       <exclusion> 
        <groupId>fi.path.to.dependency</groupId> 
        <artifactId>internal-dependency-#2</artifactId> 
       </exclusion> 
       <exclusion> 
        <artifactId>internal-dependency-#3</artifactId> 
        <groupId>fi.path.to.dependency</groupId> 
       </exclusion> 
       <exclusion> 
        <artifactId>internal-dependency-#4</artifactId> 
        <groupId>fi.path.to.dependency</groupId> 
       </exclusion> 
       <exclusion> 
        <artifactId>internal-dependency-#5</artifactId> 
        <groupId>fi.path.to.dependency</groupId> 
       </exclusion> 
       <exclusion> 
        <artifactId>castor-xml</artifactId> 
        <groupId>org.codehaus.castor</groupId> 
       </exclusion> 
       <exclusion> 
        <artifactId>castor-codegen</artifactId> 
        <groupId>org.codehaus.castor</groupId> 
       </exclusion> 
       <exclusion> 
        <artifactId>castor-xml-schema</artifactId> 
        <groupId>org.codehaus.castor</groupId> 
       </exclusion> 
       <exclusion> 
        <artifactId>internal-dependency-#6</artifactId> 
        <groupId>fi.path.to.dependency</groupId> 
       </exclusion> 
      </exclusions> 
      <version>2.6</version> 
     </dependency> 

que se incluyó sólo un cliente de servicio, imaginar tener varios de estos en varias aplicaciones diferentes y se obtiene la imagen, la redacción de todos los excluye cada vez es bastante molesto y el proyecto Los POM empiezan a ser bastante largos.

Marcaría la dependencia tal como se proporciona, pero hay un par de dependencias que se bloquean en el tiempo de ejecución, si es que no existen. Digamos los que incluyen otra llamada de servicio a otra aplicación con una clase Exception externa, que no está, por una razón u otra, envuelta dentro del proyecto de servicio y causará una ClassNotFoundException en tiempo de ejecución, si no está presente.

Por lo tanto, sé que es posible excluir/incluir clases de un cliente ejb durante su generación mediante el uso de las especificaciones pom.xml en maven-ejb-plugin, pero ¿hay alguna forma de excluir dependencias también?

Respuesta

1

Parece que Maven simplemente no admite la construcción de múltiples recipientes de un módulo muy bien.

Por lo tanto, la única forma razonable de solucionar esto que hemos encontrado es crear otro módulo (dividir el servicio xxx en xxx-service y xxx-service-client) y configurar el módulo xxx-service-client para tener solo el Cliente EJB/delegar clase & dependencias mínimas. De esta forma, el proyecto se puede construir con una sola ejecución.

0

Tengo el mismo problema aquí. Yo creo una solución podría ser el uso de perfiles, ya que en cada perfil puede especificar las dependencias (véase http://blog.sonatype.com/people/2010/01/how-to-create-two-jars-from-one-project-and-why-you-shouldnt/)

En mi caso, esto no funciona, porque necesito generar tanto JAR (EJB y ejb- cliente) en una sola ejecución de Maven. :)

+0

Enfrentando un problema similar, comenzar a cambiar la forma en que se crean los proyectos a través de la solución de CI probablemente sea una gran molestia y se convierta en un problema con el mantenimiento, cuando funcionan de manera diferente al resto de aplicaciones de la compañía. – t0mppa