Asesoramiento sobre una buena herramienta de compilación de Java, bien integrada con eclipse

Question

Estoy trabajando en un pequeño equipo (3 personas) en varios módulos (aproximadamente 10 en la actualidad). La compilación, integración y administración de las versiones de compilación es cada vez más tediosa. Estoy buscando una buena herramienta de compilación/integración para reemplazar/completar Ant.

Aquí está la descripción de nuestro entorno de desarrollo actual: - Varios módulos en función de cada una y en los frascos de terceros - Algunos pueden exportar los JAR, algunas guerras de exportación, algunos independiente de exportación, tarros ejecutables (con Fat-Jar) - Javadoc para todos ellos - Trabajamos con eclipse - Script Ant personalizado para cada módulo. Mucha información redundante entre la configuración de eclipse y los scripts Ant. Por ejemplo, para el Fat-JAR independiente, hemos enumerado todas las dependencias recursivas, mientras que, idealmente, podría importarse claramente desde la configuración del eclipse. - El código fuente se versiona con el SVN

Esto es lo que me gustaría una herramienta perfecta integración a hacer por mí:

• automatizar las versiones y versiones de los módulos. Idealmente, la herramienta de integración debería detectar si se necesita una nueva versión. Por ejemplo, si quiero lanzar un proyecto A que depende de un proyecto B, y si he realizado pequeños cambios en el proyecto B localmente, entonces la herramienta de integración también debe liberar una nueva versión de B y hacer que A se base en eso.

• Integre fuertemente con eclipse, para que pueda obtener las dependencias entre los módulos y las librerías de terceros desde su configuración. Por cierto, me gustaría continuar configurando la ruta de compilación con eclipse sin actualizar algunas otras cosas ".xml". Vi que Gradle puede generar archivos de proyecto de eclipse a partir de su configuración, pero la contraparte sería genial.

• Permiten un desarrollo "vivo" y transparente en proyectos locales. Quiero decir que a menudo hago pequeños cambios en los proyectos centrales/comunes mientras desarrollo los proyectos principales/"hoja". Me gustaría que mis cambios en los proyectos centrales estén inmediatamente disponibles para los proyectos sin necesidad de publicar (incluso localmente) los JAR de mis proyectos centrales.

• Almacene todas las versiones de las versiones de mi módulo en un servidor externo. La más simple (carpeta compartida/Webdav) sería la mejor. Una buena página web con una lista de módulos y artefactos entregados sería genial también.

He buscado muchas cosas. Desde Ant4eclipse (para integrar la configuración de Eclipse en mi script Ant), a las herramientas Maven/Ivy/Gradle.

Estoy un poco confundido. Esto es lo que he entendido hasta ahora: - Maven es una gran/gran herramienta, pero es algo rígida y te obliga a apegarte a su estructura y conceptos. Se basa en la descripción en lugar de en secuencias de comandos. Si te sales del camino, debes desarrollar tus propios complementos. - Ivy es menos poderoso que maven, maneja menos cosas pero es más flexible. - Gradle está en el medio. Es de propósito general. Permite la creación de secuencias de comandos, así como la configuración "basada en la convención". Integra Ant y lo extiende.

Por lo tanto, en este momento estoy buscando testimonios reales de usuarios reales. ¿Qué herramientas usas? Cómo ? ¿Tienes las mismas necesidades que yo? ¿Facilita su vida o se interpone en el camino?

¿Hay ejemplos de algunos casos de uso, o esqueletos de espacios de trabajo que podría usar como punto de partida para ver de qué son capaces estas herramientas?

Disculpe por la duración de este mensaje. Y gracias de antemano por su consejo.

Saludos cordiales,

Raphael herramientas

Answer 1

Automatizar los lanzamientos y versiones de los módulos (...)

Los conceptos de control de versiones y un repositorio están incorporados con Maven y que podrían caber aquí.

Maven admite SNAPSHOT dependencies. Al usar una instantánea, Maven intentará periódicamente descargar la última instantánea disponible de un repositorio cuando ejecute una compilación. SNAPSHOT se utilizan normalmente cuando un proyecto está en desarrollo activo.

Maven 2 también es compatible con version ranges (realmente no los recomiendo, pero esa es otra historia) que permiten, por ejemplo, configurar A para depender de la versión [4.0,) de B (cualquier versión superior o igual a 4.0). Si compila y lanza una nueva versión de B, A la usaría.

Integrar fuertemente con Eclipse

El m2eclipse plugin proporciona sincronización bidireccional con Eclipse.

Permiten un desarrollo "vivo" y transparente en proyectos locales.

El plugin es compatible con m2eclipse "resolución de espacio de trabajo": si el proyecto Un proyecto depende de si el proyecto B y B está en el espacio de trabajo, se puede configurar un depender de fuentes B y no en B.jar (que es el valor por defecto modo si no estoy equivocado). Entonces, un cambio en las fuentes B sería directamente visible, sin la necesidad de construir B.jar.

Almacene todas las versiones de las versiones de mi módulo en un servidor externo.

Como se mencionó anteriormente, este es en realidad un concepto central de Maven (ni siquiera tiene la opción) y la implementación a través de archivos: // o dav: // son compatibles.

---

En resumen, Maven es (probablemente) no es el único candidato, pero estoy seguro de que encajaría:

• Su proyecto no es tan exótico o compleja, no hay nada de asustar su descripción (es probable que se requiera una refacturación de la estructura, pero esto no debería ser un gran problema).
• Maven también ofrece un flujo de trabajo basado en las mejores prácticas.
• m2eclipse proporciona una fuerte integración con el IDE.

Pero Maven tiene algo de curva de aprendizaje.

Answer 2

CI? Para mí, solo hay uno: the Hudson CI.

---

he configurar un entorno de desarrollo de software para Java una vez, con los componentes:

• IDE Eclipse
• mercurial
• Bugzilla
• experto
• Nexus
• Hudson CI

y algunos apache, mysql, php, perl, python, .. para la integración.

El hudson no estaba integrado con eclipse y eso fue a propósito, porque quería construir en un servidor por separado. para todas las otras herramientas tuve una integración cruzada perfecta (como: mylyn en eclipse para hablar con bugzilla, m2eclipse para usar maven eclipse, muchos complementos para hudson, ...)

Answer 3

Algunos de sus temas son parte de implementación y administración de versiones.

podría retirar un producto como: Xebia DeployIt
(con un personal edition que es gratuito)

Answer 4

Tener un vistazo a Ant Ivy. http://ant.apache.org/ivy/

Answer 5

No hay balas de plata, pero en mi experiencia Maven es una gran herramienta de gestión de proyectos. Personalmente, me gusta usar una combinación de subversión (para control de versiones), maven (para gestión de proyectos/compilación) y hudson (para compilación/integración continua).

Encuentro que la convención presentada por maven es realmente útil para el cambio de contexto, y excelente para la administración de dependencias. Puede ser frustrante que los archivos jar no estén en los repositorios, pero puede instalarlos localmente y, cuando esté listo, puede alojar su propio repositorio privado que refleje otros lugares. He tenido una buena experiencia al usar sonar.nexus por http://www.sonatype.com/. También proporcionan un excelente libro gratuito para que comiences.

Puede parecer exagerado ahora, pero la configuración de un buen entorno de compilación/prueba/integración/liberación ahora, pagará dividendos más adelante. Siempre es más difícil adaptarse, y es algo que puedes replicar fácilmente.

Por último, me suceda a preferir la integración de Netbeans experto, pero eso es sólo conmigo :)

Answer 6

Hemos estado empezando a integrar Gradle en nuestro proceso de acumulación, y puedo añadir a las respuestas ya publicadas que haría Gradle Además trabajo. Sus suposiciones son en su mayoría correctas, gradle está más fuera de lugar, pero es potente y permite secuencias de comandos y tal dentro de la construcción en sí. Parece que la mayoría de las cosas que Maven puede hacer, también lo hace Gradle.

Ahora para sus puntos individuales:

de versiones: Gradle soporta mapas de dependencia, control de versiones, y si se agrega en un servidor de CI, que pueden desencadenar automatizado/construye dependiente. Por ejemplo, casi todos nuestros 'entregables' son .wars, pero tenemos varios libs de código (.jars) y un ejecutable .jar en desarrollo. Una configuración es hacer que las guerras y el "frasco de grasa" dependan de las bibliotecas de códigos compartidos. Luego, cuando se actualicen las bibliotecas compartidas, ubique las versiones en las bibliotecas compartidas, pruebe los proyectos que consumen, luego use la capacidad de Hudson para activar proyectos dependientes para redesplegarlos. Hay otras formas, pero parece que funciona mejor para nosotros, por ahora.

Integre con fuerza con eclipse: Tiene razón, gradle puede generar los archivos de eclipse. Tendemos a utilizar solo la tarea eclipseCp (para actualizar .classpath) una vez que nos ponemos en marcha, ya que solo se han modificado las rutas de clases. Es un tanto peculiar (toma tu JRE predeterminado, así que asegúrate de que sea correcto, no agrega exported = "true" si lo necesitas), pero te lleva el 99% del camino hasta allí.

Habilite un desarrollo "vivo" y transparente en proyectos locales: De este no estoy seguro. Solo he pirateado gradle en este caso; eliminando el artefacto en el proyecto consumidor y marcando el proyecto compartido como tal en eclipse, y luego revertido después.

Almacene todas las versiones de las versiones de mi módulo en un servidor externo: simple y se admiten muchos enfoques, similar a Maven.

En cuanto a los ejemplos, los documentos para gradle son buenos, así como los proyectos de ejemplo que vienen con el código postal completo. Te pondrán en marcha rápidamente.