with pom java maven-2 build-automation buckminster

java - pom - ¿Por qué elegir Buckminster sobre Maven?



pom maven (7)

Me pregunto por qué nadie mencionó a Tycho . Tycho ha sido propuesto como Eclipse Project y ahora en Incubating Phase .

Traté de llevarme bien con Buckminster, pero ahora echaré un vistazo a Tycho. Esto tiene los siguientes motivos:

  • Como se mencionó, la documentación de buckminster es realmente mala.
  • En realidad, nunca obtuve uno de los ejemplos de Buckminster en ejecución.
  • Sé que Maven y la documentación es en mi humilde opinión mejor que la de Buckminster.
  • Quiero usar un servidor de compilación (Jenkins) y la integración de Maven es bastante buena.

No tengo experiencia en este momento con Tycho, pero parece prometedor.

He estado usando Maven durante varios meses y estoy bastante cómodo con la forma en que funciona conceptualmente y en la práctica.

También he examinado bastante a Buckminster (pero aún no he llegado a ejecutar las muestras) para intentar averiguar qué es y cómo se compara. La documentación es pobre. Por ejemplo, usan terminología como Build Automate and Deploy, pero aún no he visto nada acerca de la implementación. La migración por etapas es otro tema insinuado pero no discutido.

Tanto Maven como Buckminster le dan la capacidad de especificar dependencias y, en general, administrar la compilación, probar y posiblemente implementar procesos.

Ambos tienen integración de eclipse y deberían ambos (habiendo usado solo Maven) trivializar la configuración y el intercambio de proyectos basados ​​en eclipse y sus dependencias.

Las principales diferencias que puedo ver son:

  • Dependencias:

    • Buckminster puede especificar dependencias que viven en repositorios de origen y su propio tipo de repositorio, además de poder hacer referencia a los repositorios de Maven para las dependencias.
    • Buckminster puede agrupar dependencias en distribuciones virtuales y también es consciente de la plataforma. La agrupación de software ciertamente parece posible en Maven con poms que hacen referencia a otras dependencias y las agrupan.

  • Construir

    • Maven usa un sistema de compilación implícita basado en el diseño. Es muy fácil crear un proyecto predeterminado, colocar las cosas donde se espera que estén y tener más capacidad de compilación, prueba y creación de jar. Al mismo tiempo, ser implícito también puede ser constrictivo. Tienes que vivir con la forma en que Maven hace las cosas.
    • Buckminster: No tengo claro cómo Buckminster decide qué construir y cómo construirlo. Parecería que esto se alinearía con el proceso del eclipse por hacer lo mismo. Buckminster también permite el uso de hormiga, pero no está claro si esto es un requisito. Por lo menos, el ciclo de vida está menos (¿?) Definido para bueno o malo, lo que permite más flexibilidad.
    • Ambas herramientas permiten construcciones sin cabeza, aunque Buckminster puede llevar consigo un poco más de equipaje.

  • Complementos

    • Maven tiene un conjunto muy extenso de complementos para todas las fases del ciclo de vida de muchos tipos diferentes de automatización, desde la generación de código hasta la ejecución de servicios integrados para pruebas.
    • Buckminster no parece tener el mismo concepto de complementos. Hay lectores y actores, pero no parecen jugar el mismo papel. Buckminster debería tener acceso al amplio conjunto de complementos disponibles para la hormiga. No está claro qué tan bien las acciones de hormiga se pueden integrar sin problemas con el resto de los procesos de Buckminster (esto también es un problema para el plugin maven ant).

  • Despliegue

    • Maven tiene una serie de complementos para generar distribuciones de software (ensamblajes) y moverlos (vagones). ¿Buckminster obtiene todo esto de Ant?

  • Complejidad

    • Los diferentes esquemas para Buckminster pueden ser bastante complejos, entre CPECs, RMAPs, MSPECs, etc.
    • Maven es algo más simple en cuanto a configuración, aunque puede volverse complejo con proyectos grandes y de múltiples módulos. Maven también tiene Archetypes para la creación sencilla de nuevos proyectos.

  • Documentación

    • Ambos son malos. ;-)
    • Buckminster es muy superficial, en cuanto a la documentación. No hay suficientes ejemplos disponibles.
    • Los plugins de Maven tienden a tener una documentación muy pobre, lo que dificulta su correcto funcionamiento.

Desde mi punto de vista, la mayor parte de lo que quisiera hacer con Buckminster lo puedo hacer con Maven. La "materialización" del control de la versión es una ventaja, pero los desarrolladores dentro de una organización pueden publicar instantáneas maven en un repositorio para compartir entre ellos, además de simplemente proporcionar versiones fijas.

Parece que hay más flexibilidad y libertad de las restricciones del ciclo de vida de Maven (¿alguna vez quisiste agregar otra fase, como la prueba posterior para la limpieza? Tengo que esperar a que lo hagan en el núcleo).

¿Qué me estoy perdiendo? ¿Hay alguna cantidad importante de funcionalidad en Buckminster que valga la pena en complejidad?

¿Hay alguna declaración locamente inexacta arriba (dado que no soy un usuario de Buckminster y solo un usuario de Maven de nivel bajo-medio)?

Maven usa un sistema de compilación implícita basado en el diseño. Es muy fácil crear un proyecto predeterminado, colocar las cosas donde se espera que estén y tener más capacidad de compilación, prueba y creación de jar. Al mismo tiempo, ser implícito también puede ser constrictivo. Tienes que vivir con la forma en que Maven hace las cosas.

En realidad, puedes especificar explícitamente dónde colocas las cosas en Maven. Las ubicaciones predeterminadas son solo eso, predeterminadas, fáciles de anular, aunque rara vez hay una buena razón para hacerlo.

Buckminster: No tengo claro cómo Buckminster decide qué construir y cómo construirlo. Parecería que esto se alinearía con el proceso del eclipse por hacer lo mismo. Buckminster también permite el uso de hormiga, pero no está claro si esto es un requisito. Por lo menos, el ciclo de vida está menos (¿?) Definido para bueno o malo, lo que permite más flexibilidad.

Creo que Maven tiende a seguir la filosofía de los valores predeterminados sensibles que son fácilmente anulables.

Maven es algo más simple en cuanto a configuración, aunque puede volverse complejo con proyectos grandes y de múltiples módulos. Maven también tiene Archetypes para la creación sencilla de nuevos proyectos.

La verdadera fortaleza de Maven radica en su gestión de las dependencias y esto tiende a brillar particularmente bien en proyectos complejos con múltiples subproyectos. Es bastante fácil definir una jerarquía de subproyectos y hacer que funcione.

Documentación: Ambos son malos. ;-)

No puedo estar en desacuerdo con eso!

Mi comprensión ( extremadamente limitada ) de Buckminster en pocas palabras es que es un sistema para versionar y compartir configuraciones de proyectos de Eclipse para un conjunto de proyectos entre los miembros del equipo. Parece superponerse con Maven, ya que gestiona las dependencias, pero creo que se trata de dependencias de nivel de proyecto Eclipse y no de dependencias de Java.

Personalmente, no quisiera vincular mi proceso de compilación a Eclipse ni a ningún otro IDE. Hay muchos beneficios de poder realizar una compilación completa desde una herramienta de línea de comandos sin la necesidad de un IDE u otra herramienta de GUI.

El libro gratuito de O''Reilly Maven: The Definitive Guide está magníficamente escrito y realmente llena la brecha de documentación de Maven.

La mayor ventaja de usar Buckminster es cuando compila paquetes OSGi o complementos Eclipse, ya que puede reutilizar la infraestructura de compilación PDE, que maneja todo tipo de información de versiones ya presente en los archivos manifest.mf / plugin.xml. Al usar Maven, esta información debe ser duplicada (AFAIK). Si no desarrolla los plug-ins de Eclipse, y ya está familiarizado con Maven, entonces Buckminster no ofrecerá ninguna ventaja real, especialmente teniendo en cuenta la curva de aprendizaje empinada. Por otro lado, para compilar complementos de Eclipse ofrece una mejor compatibilidad con la caja.

Puedes ampliar Buckminster escribiendo nuevos lectores (para obtener fuentes de otras ubicaciones) o nuevos actores (que proporcionan pasos de compilación: estos actores pueden reutilizar Maven o Ant, proporcionando así una funcionalidad adicional).

Algunas aclaraciones

  • Dependencias

    Buckminster no tiene un tipo de repositorio propio. Tiene un mecanismo de descubrimiento que traduce los metadatos existentes, como un Maven POM, en un modelo que Buckminster puede comprender. Estos metadatos se pueden agregar literalmente como un archivo XML si no se puede derivar de ninguna otra manera.

  • Construir

    Buckminster decide qué construir de la misma manera que Eclipse IDE. Además de eso, extrae información de artefactos conocidos, como el manifiesto, build.properties, plugin.xml, etc. y lo traduce en acciones en el modelo que pueden activarse explícitamente con el comando Buckminster perform.

    No estoy del todo convencido de que Buckminster lleve más equipaje para construcciones sin cabeza. De hecho, creo que lo opuesto es más común. La construcción con Maven en una máquina vacía a menudo comienza con la descarga de una gran cantidad de componentes, incluso si la tarea en cuestión es trivial.

  • Complementos

    Buckminster se basa en OSGi y se extiende con los puntos de extensión de Eclipse. Es posible agregar nuevos tipos de repositorios, nuevos tipos de acciones, nuevos mecanismos de descubrimiento y más usando este mecanismo.

  • Complejidad

    Una configuración mínima de Buckminster solo necesita un CQUERY y un RMAP. Con ellos, es posible crear un sitio de actualización p2 completo de tamaño arbitrario que se firma y procesa con pack200. No es necesario agregar archivos a ninguna de las funciones y paquetes. Nada necesita ser "Buckminsterized". Así que no estoy seguro de estar de acuerdo con que Maven sea más simple de configurar.

Además de los beneficios ya mencionados por Roland y Zoltán, me gustaría añadir que dado que la construcción de Buckminster es una verdadera construcción de espacio de trabajo, aprovechará todos los constructores que se hayan declarado en el archivo .project. Aquí hay unos ejemplos:

  • Constructor de PDE Manifest: genera advertencias y errores de manifiestos, archivos de propiedades, etc.
  • Creador de esquemas PDE (lo mismo para los esquemas de puntos de extensión)
  • Todos los demás constructores hicieron para la estructura Eclipse Build. Esto incluye constructores de validación de esquemas XML, constructores de Java Script y muchos otros.
Estoy seguro de que Maven tiene correspondencia para la mayoría de ellos. El punto con Buckminster es que no necesitas mantener un sistema de compilación extra. Lo que funciona en el espacio de trabajo IDE, también funciona sin cabeza.

Debido a la falta de documentación de Buckminster, creé un ejemplo de Building Products con Buckminster / Hudson . Esto puede ayudar a comenzar, también funciona con Jenkins .

Utilicé el tutorial de Ralf para obtener una buena visión general sobre el tema.

Plataforma de destino

Cómo configurar Hudson y Buckminster se puede leer en el tutorial de Ralf. Pequeño truco, para evitar OutOfMemoryErrors, agregue -Xmx1024m a los "parámetros adicionales" de su instalación Buckminster (consulte la sugerencia de solución de problemas Hudson sin memoria ).

Tengo un trabajo separado de estilo libre para publicar mi plataforma de destino para otros trabajos. En la sección "Gestión de código fuente", seleccioné la función que contiene mi definición de destino (en mi caso, ch.scodi.client.site).
Para resolver realmente la definición del objetivo, agregué un paso de compilación "Ejecutar Buckminster" con el siguiente comando:

importtargetdefinition -A ''${WORKSPACE}ch.scodi.client.site/TargetDefinition.target''

En el Post-Build-Action revisó "Archivar y publicar una plataforma de destino de Eclipse" y agregó .metadata/.plugins/org.eclipse.pde.core/.bundle_pool como ruta de acceso.

Tenga en cuenta que TargetDefinition no puede resolver las ubicaciones del directorio. Mi definición de destino solía tener una ubicación de directorio que contenía paquetes del depósito de springsource.
Intenté usar el archivo rmap para obtener los paquetes durante la materialización, pero tuve algunos problemas con eso, así que decidí crear un sitio de actualización propio para esos paquetes y agregar este sitio a la definición del objetivo. Más sobre eso se puede encontrar aquí:
http://www.eclipse.org/forums/index.php?t=msg&th=164508&start=0&

Construyendo el Producto

Después de ejecutar el trabajo de definición de objetivos, podemos comenzar a construir los productos.
Esto es bastante directo, consulte el tutorial de Ralf sobre cómo verificar su fuente desde SVN.
Tengo tres compilaciones diferentes para cada producto de servidor y cliente: Integración, Noche y Versión.
Para cada compilación, el calificador del complemento debe ser diferente (por ejemplo, I20100326-2, N20100326, R20100326-01). Para lograr esto, instalé el plugin Flow:
http://wiki.hudson-ci.org/display/HUDSON/Version+Number+Plugin
En el trabajo de integración elijo "Crear un número de versión formateado", lo llamo "versión" y utilizo algo como este I${BUILD_YEAR, XXXX}${BUILD_MONTH, XX}${BUILD_DAY, XX}-${BUILDS_TODAY} como formato.

Para finalmente construir el producto del cliente, agregué un paso de compilación de Buckminster, seleccioné la plataforma objetivo publicada anteriormente y usé los siguientes comandos:

import ''${WORKSPACE}source/scodi-rcp/features/ch.scodi.client.site/site.cquery'' build perform -D target.os=* -D target.ws=* -D target.arch=* -D qualifier.replacement.*=${version} ch.scodi.client.site#site.p2.zip perform -D target.os=win32 -D target.ws=win32 -D target.arch=x86 ch.scodi.client.site#create.product.zip perform -D target.os=win32 -D target.ws=win32 -D target.arch=x86_64 ch.scodi.client.site#create.product.zip

Observe qualifier.replacement.*=${version} , esto le dice a Buckminster / Eclipse que use mi versión formateada como calificador y los resultados en complementos nombrados como este com.softmodeler.model_1.0.0.I20100325-3.jar , requiere que Bundle-Version: 1.0.0.qualifier se define en el manifest paquete.

http://flaviodonze.blogspot.ch/2010/03/building-products-with.html