Buildr, Gradle o esperar a Maven 3? [cerrado]

Question

Estoy muy cansado de luchar con Maven 2 todo el tiempo. herramientas de construcción no deben estar en el camino. Recientemente he estado buscando en Buildr y Gradle. Maven 3 parece solucionar algunas de las luchas. Por lo tanto, lo que debería ir por ahora? Buildr? Gradle? O esperar un año para Maven 3?

Answer 1

No existe un sistema de construcción es una bala mágica. Encuentro Maven resuelve más problemas que hace que para mí, pero estoy escribiendo plugins bastante cómodo para evadir sus deficiencias, también trato con cientos de proyectos, por lo que la herencia de Maven y el procesamiento de la dependencia es muy útil para mí.

Vea así que un poco y verá Buildr y Gradle ambos tienen problemas demasiado (lo mismo para Ant y Hiedra), en general, que usted opera un conjunto de problemas por otro y es un caso de encontrar el menos doloroso.

¿Hay algo en particular que le está molestando sobre Maven o se trata de una picazón en general? Si se trata de un problema particular, vale la pena mirar el Maven 3 números en Jira , si el problema no se menciona, puede elevar, o bien puede haber mucho sentido que esperar

Answer 2

Yo no esperaría demasiado de Maven 3. La gente detrás del pedigrí Maven de herramientas de construcción han sido siempre de la premisa de que proyecto se basa son homogéneos, es decir: todos los problemas de compilación fundamentalmente se reducen a un mismo problema. Esta visión del mundo se hace de manera consistente en la cara de puntos de vista opuestos, pero tiene un costo. La ausencia de la lógica de secuencias de comandos en Maven ( "cuando se quiere guión sabes que estás haciendo algo malo"), la API de plugins engorroso ( "ningún usuario normal Maven debe querer escribir un plugin") y el repositorio central ( "nosotros todos tienen las mismas dependencias ") son todos los testamentos de esta suposición general.

En el mundo real construir problemas son heterogéneos debido a las personas a construir el software para una amplia variedad de razones. Todos ellos 'desarrollar' como que una vez que todos los agujeros de perforación '' desde hace tiempo para la solución de problemas específicos. Independientemente de su nivel de abstracción que siempre encontrará similitudes al comparar los problemas de construcción arbitrarias. Es la reveration de estas similitudes y diferencias de la condena que es la caída para el diseño de Maven y la razón por la que atrae tanto antibalas. Básicamente, Maven es autoritario y utópico en su perspectiva.

PS:. Maven tiene buenas características, como la convención-sobre-configuración y la idea de usar los repositorios (la puesta en práctica de esta idea Maven es problemático)

Answer 3

Utilizamos Maven aquí, pero me parece que una vez que llegue fuera de un proyecto simple, el pom.xml comienza a ser más y más compleja. Usted comienza a pasar mucho tiempo trabajando cómo diablos para configurar su pom para hacer lo que quiere, y cómo evitar los diversos problemas.

Lo que realmente me fue el oído que estamos construyendo. Tenemos múltiples guerras en ese archivo del oído, y Maven normalmente palos de las bibliotecas en las guerras. Sin embargo, para reducir el tamaño de las guerras, y para mantener los frascos de todos modos, queríamos poner los frascos compartidos entre las guerras en el directorio lib de la oreja.

Por desgracia, Maven no maneja muy bien. Teníamos que configurar manualmente esto para cada uno de los poms Wars', y luego añadir todas estas dependencias en pom de la oreja.

En otro proyecto que tenemos los archivos de ayuda basado en HTML. Las personas que escriben la ayuda a escribir en Microsoft Word a continuación, utilizar un programa para traducirlos en HTML. Un cambio solo carácter puede resonar a través de cientos de archivos.

Para solucionar este problema, nuestro sistema de ayuda se almacena en nuestro repositorio de código fuente como un solo archivo comprimido. Cuando nuestro equipo de documentación crea un nuevo conjunto de archivos de ayuda, que la cremallera y reemplazar lo que está en el repositorio.

Por lo tanto, parte de mi construcción está bajando la cremallera de este archivo y colocarlo en la guerra. Fácil de hacer en la hormiga, no puede hacerlo en Maven a menos que utilice el plugin antRun que le permite escribir código Ant para manejar los problemas que Maven no puede manejar sin un complemento completo soplado.

Puedo ver lo que está haciendo Maven, pero la teoría adelantado a la realidad. Lo que encontré es que la hiedra y Ant pueden hacer la mayor parte de la comprobación de dependencia Maven que prescinde de todas las cuestiones de redactar y mantener los poms.

Si usted aún no está utilizando Maven, Ant tratar con Ivy primero. Luego, cuando, Maven 3 sale, trate de eso. Recuerdo la transición de Maven Maven 1 a 2. Ellos eran totalmente incompatibles entre sí y todo lo que aprendieron utilizando Maven 1 era obsoleta. Sería tonto para aprender y rehacer sus proyectos de Maven 2 a encontrarse de repente volver a hacer todo lo necesario para Maven 3.

Answer 4

3.x experto ya está incrustado en IDEs (al menos en netbeans, comprobar este enlace para obtener más infomration). Puede jugar hoy con Maven 3.x simple construcción de un proyecto Maven con NetBeans.

Otra buena noticia es que la experta consiguió más apoyo 'empresa' con la integración de EJB / WS en proyectos de IDE (de nuevo, al menos en netbeans).

Así que se pegaba a maven 2.x para la producción construye y jugar con 3.x experto para el desarrollo.

Answer 5

Maven 2 y 3 tienen ambas estado trabajando perfectamente para mí en una variedad de proyectos. Actualmente estoy usando Maven 3 alfa 7 que funciona muy bien, especialmente en conjunción con el plugin Eclipse Maven.

Maven se integra perfectamente con Ant - en ambas direcciones. En mi proyecto actual, invocamos Maven desde Ant varias veces con el fin de realizar la prueba de integración compleja. Del mismo modo, utilizamos hormiga a través de plug-in antRun de Maven, y también escribimos nuestros propios plugins de Maven. Esto, por cierto, es una cuestión de minutos y se reduce a escribir un Pojo anotada.

Maven consigue un montón de críticas debido a que muchos desarrolladores no les gusta reglas o convenciones. En pocas palabras, nadie te obliga a usar Maven. Si quieres libertad definitiva - por cualquier medio - re-escribir su propio proceso de construcción para cada proyecto se inscribe. Sin embargo, si se quiere crear software en lugar de reinventar la rueda con un proceso de construcción a medida de cada proyecto, ir a por Maven.

Answer 6

Mantenga su código bien mantenido y dividido en módulos bien definidos y lumbreras entre los sistemas de construcción se convierte en un problema menor.

Por el momento, maven-2 es una buena opción para el medio 2/3 de los proyectos. Para el muy simple, hormiga sigue siendo buena. Para los más complejos, un híbrido de maven-2 y otras herramientas (como antRun) se hace inevitable.

No sé por qué usted está teniendo problemas con maven-2.

Se diferencia de las hormigas y Buildr en que se trata de una herramienta para describir el proceso de construcción, no es de secuencias de comandos. Complejo construye, los que tienen múltiples partes dinámicas y dependencias anidadas y / o transitorios son difíciles de construir, ya que son difíciles de describir.

Answer 7

https://github.com/hackingspirit/Lattice intentarlo. Yo soy el autor. Aquí está la primicia:

En Entramado construir archivos se escriben no en XML, pero en el lenguaje Python. Los benefi- cios son mucho mejor legibilidad y potente scripting acumulación imprescindible el apoyo de Python. Para los proyectos de módulos múltiples. Celosía utiliza clasificación topológica para decidir el orden correcto para construir cada módulo. También está previsto que Entramado analizará la dependencia del módulo para determinar la forma en la compilación del módulo se puede paralelizar. el código fuente de celosía está extremadamente delgado, en la actualidad se compone de alrededor de 500 líneas de código fuente de Python.

Answer 8

Creo que la gente se queja de Maven deben pasar un poco de tiempo extra investigando plugins disponibles. En respuesta a los comentarios quejándose de que Maven es rígido y hace que sea difícil de usar encargo de la estructura lógica / proporcionar un control preciso sobre el proceso de construcción - Yo recomiendo mirar en el plug-in de la hormiga por Maven (en realidad hay varios, pero aquí es una : http://maven.apache.org/plugins/maven-antrun-plugin). He tenido un gran éxito personalización de Maven construye con él en los últimos años. Básicamente, se le permite ejecutar cualquier comando Ant como parte de la construcción Maven, y se puede hacer casi cualquier cosa con Ant;)

Answer 9

hormiga con Ivy hace lo mismo Maven gestión de la dependencia hace (de hecho, se utiliza toda la infraestructura de gestión de la dependencia de Maven incluyendo los mismos repositorios URL), pero sin todo el lío de configuración POM.

hormiga con Ivy podría ser una manera de manejar los problemas de dependencia para las personas que realmente no quieren usar Maven. Soluciona el 90% de las cosas que Maven se supone que debe resolver.