cambiando a gradle de maven para gestionar un gran proyecto osgi (> 200 paquetes)

Question

Tenemos un gran proyecto (~ 215 paquetes y contando) osgi (felix + springdm), compilación con el plugin maven y maven-osgi.

Hemos varios problemas con forma experta:

1. submódulos pom tiene que heredar de los padres pom para tomar ventaja de las variables y dependencias comunes (que está bien), pero luego pom padre tiene que incluir todos los paquetes a POM ser capaz de construir todo en conjunto. Este tipo de referencia circular hace que sea muy difícil mantener todo sincronizado.

2. la versión individual de los subgrupos era tan compleja que se decidió (antes de unirme al proyecto) utilizar la misma versión para todos los paquetes. Esto significa que ahora actualizamos la versión de todos los paquetes para cada versión también si solo se cambian algunos de ellos. Esto hace que todo el concepto de osgi sea un poco sin sentido en mi humilde opinión. Tenga en cuenta que no estoy diciendo que continuemos tocando solo una pequeña cantidad de paquetes, trabajamos en todos ellos, pero cada versión por lo general contiene 1 o 2 funciones, lo que afecta solo a algunos paquetes.

3. Para realizar el paquete y la implementación del artefacto final, necesitamos otro submódulo que importe todos los paquetes necesarios para la implementación (todos salvo unos pocos para pruebas y simulacros). [editado] Tenga en cuenta que esta agregación es diferente de la del pomo principal, ya que no compila los paquetes, sino que simplemente los selecciona del repositorio de maven.

4. el sistema de dependencia maven y las importaciones del complemento osgi a veces son difíciles de mantener alineados. Es demasiado fácil olvidar una importación o poner una dependencia incorrecta.

[editado] En cada pom paquete hay una sección de esta manera: `

  <plugin> 
      <groupId>org.apache.felix</groupId> 
      <artifactId>maven-bundle-plugin</artifactId> 
      <extensions>true</extensions> 
      <configuration> 
       <instructions> 
        <Export-Package> 
        </Export-Package> 
        <Import-Package> 
         com.google.gson, 
         org.apache.log4j, 
         org.apache.log4j.spi, 
         org.dom4j, 
         com.myinterfaces 
        </Import-Package> 
       </instructions> 
      </configuration> 
     </plugin>` 

Por todas estas razones, estamos bien, pero no muy feliz con Maven. Recientemente, alguien propuso Gradle no como una panacea, sino como una mejora definitiva sobre la situación actual.

¿Recomendarías mudar a gradle? y en caso de que sería la mejor manera?

¿Alguien más ha experimentado la misma situación? Creo que debería ser común para todos los grandes proyectos con Osgi.

Negación: buscó preguntas similares como:

Buildr, Gradle or wait for Maven 3?

Looking for a good dev environment for OSGi bundles

Maven : OSGI, bundles and multi-modules projects

pero o bien en donde no se trata de submódulos OSGi o no sobre Gradle.

Answer 1

1. Puede separar los módulos primarios y agregados de maven, porque actualmente su pom padre tiene dos funciones como las que observó correctamente. Se puede encontrar más información en el Maven Introduction to POM.
2. Me temo que la administración de versiones de paquetes no puede ser más fácil a menos que use API Tools. Tal vez sería genial si las herramientas de API se pueden integrar como complemento de Maven, pero no estoy al tanto de ningún trabajo en esta área. Entonces, puede tocar todas las versiones a la vez o actualizarlas cada vez que las necesite.Las herramientas de API serán de gran ayuda aquí, pero solo funcionan para los paquetes, que se pueden importar como proyectos de complemento dentro de Eclipse.
3. Entonces, ¿otro módulo agregador ayudará aquí? Puede configurar varios agregadores, que agregan otros agregadores, para que no termine con un enorme módulo agregador que enumera todo. Debido a que es posible que no desee implementar todo, puede configurar qué excluir de la implementación. Búsqueda de Google rápida mostró cómo hacer it.
4. @Neil Bartlett ya notó que Bnd se ocupará de su manifiesto si ha configurado sus dependencias correctamente. Si necesita un ajuste adicional de los valores predeterminados, siempre puede configurar el archivo de instrucciones BND.

Puede poner a Tycho en la lista de posibles herramientas. Le ayudará con la administración de la dependencia, ya que solo debe especificar sus dependencias en el Manifiesto y le permitirá utilizar las Herramientas de la API (pero aún no hay integración). Sin embargo, requerirá que use repositorios p2 si desea saltarse algunos dolores de cabeza (hasta que Tycho haya mejorado su soporte para depender de los artefactos Maven).