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

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

En primer lugar, Gradle es una herramienta de programación de dependencias que también significa que es una herramienta de programación. Con Gradle puedes ejecutar cualquier tarea aleatoria en tu configuración y Gradle se asegurará de que todas las dependencias declaradas se ejecuten correcta y oportunamente. Su código se puede distribuir a través de 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á scripts de compilación en los directorios que se supone que debe buscar. Durante la ejecución Gradle ejecutará las tareas que se han cargado durante la evaluación teniendo en cuenta las interdependencias de tareas.

Además de estas funciones de programación de dependencias, Gradle añade funciones de dependencia de proyectos y JAR mediante integración con Apache Ivy. Como sabes, Ivy es mucho más herramienta de gestión de dependencias potente y mucho menos obstinada que say Maven.

Gradle detecta dependencias entre proyectos y entre proyectos y JARs. Gradle funciona con repositorios Maven (descarga y carga) como el iBiblio o tus propios repositorios, pero también soporta y otro tipo de infraestructura de repositorios que puedas tener.

En compilaciones multi-proyecto Gradle es adaptable y se adapta a la estructura y arquitectura de la compilación. Usted no tiene que adaptar su estructura o arquitectura a su herramienta de compilación como se requeriría con Maven.

Gradle se esfuerza mucho por no interponerse en tu camino, un esfuerzo que Maven casi nunca hace. La convención es buena, pero también lo es la flexibilidad. Gradle te ofrece muchas más funciones que Maven, pero lo más importante en muchos casos, Gradle te ofrecerá un camino de transición indoloro 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 turing completo en el que nadie realmente quiere programar.

Maven intenta tomar el enfoque opuesto de intentar ser completamente declarativo y forzarlo a escribir y compilar un plugin 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 la configuración (ala Maven) pero solo en la medida en 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% de las cosas sean fáciles y el 20% posibles (a diferencia de otras herramientas de compilación que hacen que el 80% sea fácil, el 10% sea posible y el 10% sea efectivamente imposible).

Gradle es el más herramienta de compilación configurable y flexible que aún no he utilizado. Requiere cierta inversión por adelantado para aprender el DSL y conceptos como configuraciones, pero si necesita una herramienta de compilación 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 plugins de Maven.

Así que si desea tener una compilación estándar de Java, como en maven, pero la tarea de prueba tiene que hacer algún paso personalizado que podría verse a continuación.

Construir.gradle:

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

Además de eso, utiliza una sintaxis groovy que le da mucho más poder de expresión que el xml de ant/maven.

Es un superconjunto de Ant: puedes usar todas las tareas Ant en gradle con una sintaxis más agradable y groovy, 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, y Ivy ofrece una mejor gestión de dependencias que Maven, pero no hay un gran soporte para compilaciones multi-proyecto. Terminas haciendo mucho código para soportar compilaciones multi-proyecto. También tener algunos build-by-convention es agradable y hace que los scripts de compilación sean más concisos. Con Maven, lleva la compilación por convención demasiado lejos, y personalizar su proceso de compilación se convierte en un truco. Además, Maven promueve cada proyecto publicando un artefacto. A veces tiene un proyecto dividido en subproyectos, pero desea que todos los subproyectos se construyan y versen juntos. No es 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 compilació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 para el código que XML. En Gradle, puedes definir dependencias entre proyectos en el sistema de archivos local sin necesidad de publicar artefactos para cada uno en un repositorio. Finalmente, Gradle usa Ivy, por lo que tiene una excelente administración de dependencias. El único inconveniente real para mí hasta ahora es la falta de integración de Eclipse madura, pero las opciones para Maven no son realmente mucho mejores.

Esta no es mi respuesta, pero definitivamente resuena conmigo. Es de El Radar Tecnológico de ThoughtWorks de octubre 2012:

Dos cosas han causado fatiga con herramientas de compilación basadas en XML como Ant y Maven: demasiados frenos puntiagudos enojados y la grosería del plug-in arquitectura. Mientras que los problemas de sintaxis se pueden tratar a través de las arquitecturas de generación y plug-in limitan severamente la capacidad de compilación herramientas para crecer con gracia a medida que los proyectos se vuelven más complejo. Hemos venido para sentir que los plug-ins son el nivel equivocado de abstracción, y prefieren herramientas basadas en el lenguaje como Gradle y Rake, porque ofrecen abstracciones más finas y más flexibilidad a largo plazo.

Gradle puso la diversión de nuevo en el software de construcción/montaje. Usé ant para construir software toda mi carrera y siempre he considerado que el "buildit" real parte 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 jars en el VCS) y se me dio la tarea de investigar esto. Comenzó con Ivy ya que podía atornillarse encima de ant, no tuve mucha suerte para publicar mis artefactos construidos como quería. Fui por maven y hackeado con xml, funcionó espléndido para algunas libs de ayuda simples, pero me encontré con serios problemas al tratar de agrupar aplicaciones listas para implementar. Molestó bastante tiempo googleando plugins y leyendo foros y terminó descargando trillones de tarros de soporte para varios plugins que tuve un tiempo difícil de usar. Finalmente fui por gradle (consiguiendo bastante amargo en este punto, y molesto que "No debería ser TAN difícil!")

Pero desde el primer día mi estado de ánimo comenzó a mejorar. Yo había conseguido en alguna parte. Me tomó como dos horas migrar mi primer módulo ant y el archivo de compilación era básicamente nada. Fácilmente cabido una pantalla. El gran " wow " fue: construir scripts en xml, ¿qué tan estúpido es eso? el hecho de que declarar una dependencia toma UNA fila es muy atractivo para mí -> usted puede ver fácilmente todas las dependencias para un determinado proyecto en una página. Desde entonces he estado en un rollo constante, para cada problema que he enfrentado hasta ahora hay una solución simple y elegante. Creo que estos son los razones:

• groovy es muy intuitivo para los desarrolladores de Java
• la documentación es genial para impresionante
• la flexibilidad es infinita

Ahora paso mis días tratando de pensar en 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 plugins para Maven que tratan de manejar algunos proyectos nativos, pero no hacen un trabajo efectivo. Las tareas Ant se pueden escribir para compilar 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 empezamos a introducir la gestión de dependencias en los proyectos nativos, era complicado. Nos consiguió 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 entenderlo sin convertirse en gurus Maven.

Estoy parcialmente de acuerdo con Ed Staub. Gradle definitivamente es más potente 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 atenernos a maven por dos cuestiones nos encontramos con gradle (la velocidad es más lenta que maven, el proxy no funcionaba ) .