¿Por qué usar Gradle en lugar de Ant o Maven? [cerrado]

¿Qué me da otra herramienta de compilación dirigida a Java?

Si usa Gradle sobre otra herramienta, ¿por qué?

Yo no uso a Gradle con enojo (solo un proyecto de juguete hasta ahora) [el autor significa que han usado Gradle solo en un proyecto de juguete hasta ahora, no es que Gradle sea un proyecto de juguete - ver comentarios] , pero diría que las razones por las que uno consideraría usarlo serían las frustraciones de Ant y Maven.

En mi experiencia, Ant suele ser de solo escritura (sí, sé que es posible escribir construcciones bellamente modulares y elegantes , pero el hecho es que la mayoría de las personas no lo hacen). Para cualquier proyecto no trivial, se vuelve alucinante y tiene mucho cuidado para garantizar que las compilaciones complejas sean verdaderamente portátiles. Su naturaleza imperativa puede conducir a la replicación de la configuración entre compilaciones (aunque las macros pueden ayudar aquí).

Maven adopta el enfoque opuesto y espera que se integre completamente con el ciclo de vida de Maven. Los usuarios experimentados de Ant encuentran esto particularmente discordante ya que Maven elimina muchas de las libertades que tienes en Ant. Por ejemplo, hay un blog de Sonatype que enumera muchas de las críticas de Maven y sus respuestas.

El mecanismo de complemento Maven permite configuraciones de compilación muy potentes, y el modelo de herencia significa que puede definir un pequeño conjunto de POM principales que encapsulan sus configuraciones de compilación para toda la empresa y los proyectos individuales pueden heredar esas configuraciones, dejándolas ligeras. La configuración de Maven es muy detallada (aunque Maven 3 promete abordar esto), y si desea hacer algo que "no sea la forma de Maven", debe escribir un complemento o utilizar la integración de Ant. Tenga en cuenta que me gusta escribir complementos de Maven, pero aprecio que muchos se opondrán al esfuerzo involucrado.

Gradle promete alcanzar el punto ideal entre Ant y Maven. Utiliza el enfoque de Ivy para la resolución de dependencias. Permite la convención sobre la configuración, pero también incluye tareas Ant como ciudadanos de primera clase. También sabiamente le permite utilizar los repositorios existentes de Maven / Ivy.

Entonces, si ha golpeado y se ha quedado atascado con cualquiera de los puntos de dolor de Ant / Maven, probablemente valga la pena probar Gradle, aunque en mi opinión queda por ver si no solo estaría intercambiando problemas conocidos por problemas desconocidos. Sin embargo, la prueba del pudín está en el consumo, por lo que me reservaría el juicio hasta que el producto esté un poco más maduro y otros hayan solucionado los problemas (por algún motivo lo llaman borde de sangrado). Sin embargo, todavía lo usaré en mis proyectos de juguetes. Siempre es bueno conocer las opciones.

Gradle se puede usar para muchos propósitos, es una navaja suiza mucho mejor que Ant, pero se centra específicamente en compilaciones de proyectos múltiples.

En primer lugar, Gradle es una herramienta de programación de dependencia que también significa que es una herramienta de programación. Con Gradle puede ejecutar cualquier tarea aleatoria en su configuración y Gradle se asegurará de que todas las dependencias declaradas se ejecuten de manera adecuada y oportuna. Su código se puede distribuir en muchos directorios en cualquier tipo de diseño (árbol, plano, disperso, ...).

Gradle tiene dos fases distintas: evaluación y ejecución. Básicamente, durante la evaluación, Gradle buscará y evaluará los scripts de compilación en los directorios que debe buscar. Durante la ejecución, Gradle ejecutará tareas que se hayan cargado durante la evaluación teniendo en cuenta las interdependencias de tareas.

Además de estas características de programación de dependencia, Gradle agrega características de dependencia de proyecto y JAR mediante la integración con Apache Ivy. Como saben, Ivy es una herramienta de administración de dependencias mucho más poderosa y mucho menos obstinada que Maven.

Gradle detecta dependencias entre proyectos y entre proyectos y JAR. Gradle funciona con repositorios Maven (descarga y carga) como el iBiblio o sus propios repositorios, pero también admite y otro tipo de infraestructura de repositorio que pueda tener.

En las compilaciones de proyectos múltiples, Gradle es adaptable y se adapta a la estructura y arquitectura de la compilación. No tiene que adaptar su estructura o arquitectura a su herramienta de compilación como se requeriría con Maven.

Gradle se esfuerza mucho para no interponerse en su camino, un esfuerzo que Maven casi nunca hace. La convención es buena, pero también lo es la flexibilidad. Gradle le ofrece muchas más funciones que Maven, pero lo más importante en muchos casos es que Gradle le ofrecerá una ruta de transición indolora lejos de Maven.

Esto puede ser un poco controvertido, pero Gradle no oculta el hecho de que es un lenguaje de programación completo.

Ant + ant-contrib es esencialmente un lenguaje de programación completo y duradero que nadie realmente quiere programar.

Maven intenta adoptar el enfoque opuesto de tratar de ser completamente declarativo y obligarlo a escribir y compilar un complemento si necesita lógica. También impone un modelo de proyecto que es completamente inflexible. Gradle combina lo mejor de todas estas herramientas:

• Sigue la convención sobre configuración (ala Maven) pero solo en la medida que lo desee
• Te permite escribir tareas personalizadas flexibles como en Ant
• Proporciona soporte para proyectos de múltiples módulos que es superior a Ant y Maven
• Tiene un DSL que hace que el 80% sea fácil y el 20% posible (a diferencia de otras herramientas de compilación que hacen que el 80% sea fácil, 10% posible y 10% efectivamente imposible).

Gradle es la herramienta de compilación más configurable y flexible que todavía tengo que usar. Se requiere un poco de inversión por adelantado para aprender el DSL y conceptos como las configuraciones, pero si necesita una herramienta de creación de JVM sin sentido y completamente configurable, es difícil de superar.

Gradle combina muy bien tanto Ant como Maven, tomando lo mejor de ambos frameworks. Flexibilidad de Ant y convención sobre configuración, gestión de dependencias y complementos de Maven.

Entonces, si desea tener una compilación estándar de Java, como en Maven, pero la tarea de prueba debe hacer un paso personalizado, podría verse a continuación.

build.gradle:

apply plugin:'java'
task test{
  doFirst{
    ant.copy(toDir:'build/test-classes'){fileset dir:'src/test/extra-resources'}
  }
  doLast{
    ...
  }
}

Además de eso, usa una sintaxis maravillosa que proporciona mucho más poder de expresión que el xml de ant / maven.

Es un superconjunto de Ant: puede usar todas las tareas de Ant en gradle con una sintaxis más agradable y maravillosa, es decir.

ant.copy(file:'a.txt', toDir:"xyz")

o

ant.with{
  delete "x.txt"
  mkdir "abc"
  copy file:"a.txt", toDir: "abc"
}

Usamos Gradle y lo elegimos sobre Maven y Ant. Ant nos dio una flexibilidad total e Ivy ofrece una mejor gestión de dependencias que Maven, pero no hay un gran soporte para las compilaciones de proyectos múltiples. Termina haciendo una gran cantidad de codificación para admitir compilaciones de proyectos múltiples. También tener algo de construcción por convención es agradable y hace que los scripts de construcción sean más concisos. Con Maven, lleva la construcción por convención demasiado lejos, y personalizar el proceso de construcción se convierte en un truco. Además, Maven promueve cada proyecto que publica un artefacto. A veces tiene un proyecto dividido en subproyectos, pero desea que todos los subproyectos se creen y versionen juntos. No es realmente algo para lo que Maven esté diseñado.

Con Gradle puedes tener la flexibilidad de Ant y construir por convención de Maven. Por ejemplo, es trivial extender el ciclo de vida de construcción convencional con su propia tarea. Y no estás obligado a usar una convención si no quieres. Groovy es mucho más agradable de codificar que XML. En Gradle, puede definir dependencias entre proyectos en el sistema de archivos local sin la necesidad de publicar artefactos para cada uno en un repositorio. Finalmente, Gradle usa Ivy, por lo que tiene una excelente gestión de dependencias. El único inconveniente real para mí hasta ahora es la falta de integración madura de Eclipse, pero las opciones para Maven no son realmente mucho mejores.

Esta no es mi respuesta, pero definitivamente resuena conmigo. Es del radar de tecnología de ThoughtWorks de octubre de 2012 :

Dos cosas han causado fatiga con las herramientas de compilación basadas en XML como Ant y Maven: demasiadas llaves puntiagudas enojadas y la tosquedad de las arquitecturas de complementos. Si bien los problemas de sintaxis pueden abordarse a través de la generación, las arquitecturas de plug-in limitan severamente la capacidad de las herramientas de construcción para crecer con gracia a medida que los proyectos se vuelven más complejos. Hemos llegado a sentir que los complementos son el nivel incorrecto de abstracción, y preferimos herramientas basadas en el lenguaje como Gradle y Rake, porque ofrecen abstracciones más finas y más flexibilidad a largo plazo.

Gradle devolvió la diversión al software de construcción / montaje. Utilicé hormigas para construir software durante toda mi carrera y siempre he considerado que la parte "buildit" real del trabajo de desarrollo es un mal necesario. Hace unos meses, nuestra compañía se cansó de no usar un repositorio binario (también conocido como registrar frascos en las VCS) y me dieron la tarea de investigar esto. Comencé con la hiedra, ya que podría atornillarse encima de la hormiga, no tuve mucha suerte para publicar mis artefactos construidos como quería. Fui por Maven y pirateé con xml, trabajé espléndido para algunas libs auxiliares simples, pero me encontré con serios problemas al tratar de agrupar aplicaciones listas para implementar. Me molestó bastante buscar en google complementos y leer foros y terminé descargando billones de tarros de soporte para varios complementos que me costó mucho usar.

Pero desde el primer día, mi estado de ánimo comenzó a mejorar. Estaba llegando a alguna parte. Me llevó dos horas migrar mi primer módulo de hormigas y el archivo de compilación básicamente no era nada. Se instala fácilmente en una pantalla. El gran "wow" fue: crear scripts en xml, ¿qué tan estúpido es eso? El hecho de que declarar una dependencia toma UNA fila es muy atractivo para mí -> puedes ver fácilmente todas las dependencias para un determinado proyecto en una página. A partir de ese momento, he estado en constante movimiento, por cada problema que he enfrentado hasta ahora hay una solución simple y elegante. Creo que estas son las razones:

• Groovy es muy intuitivo para los desarrolladores de Java
• la documentación es excelente
• la flexibilidad es infinita

Ahora paso mis días tratando de pensar nuevas características para agregar a nuestro proceso de compilación. ¿Qué tan enfermo es eso?

También es mucho más fácil administrar compilaciones nativas. Ant y Maven son efectivamente solo Java. Existen algunos complementos para Maven que intentan manejar algunos proyectos nativos, pero no hacen un trabajo efectivo. Se pueden escribir tareas de hormigas que compilan proyectos nativos, pero son demasiado complejas e incómodas.

Hacemos Java con JNI y muchos otros bits nativos. Gradle simplificó considerablemente nuestro desorden de hormigas. Cuando comenzamos a introducir la gestión de dependencias en los proyectos nativos, era complicado. Conseguimos que Maven lo hiciera, pero el código Gradle equivalente era una pequeña fracción de lo que se necesitaba en Maven, y la gente podía leerlo y comprenderlo sin convertirse en gurús de Maven.

Estoy de acuerdo en parte con Ed Staub. Gradle definitivamente es más poderoso en comparación con Maven y proporciona más flexibilidad a largo plazo.

Después de realizar una evaluación para pasar de maven a gradle, decidimos seguir con maven por dos problemas que encontramos con gradle (la velocidad es más lenta que maven, el proxy no funcionaba).