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?
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