Hay tres herramientas de compilación principales en el mundo de Java: Ant, Maven y Gradle. Después de varios años de desarrollo, Ant casi ha desaparecido, Maven también está desapareciendo y el desarrollo de Gradle está en pleno apogeo. El autor tuvo la suerte de presenciar el declive de Maven y el surgimiento de Gradle. Las funciones principales de Maven se dividen principalmente en 5 puntos, que son el sistema de gestión de dependencias, la construcción de módulos múltiples, la estructura de proyecto consistente, el modelo de construcción consistente y el mecanismo de complemento. Podemos analizar el avance de Gradle en comparación con Maven a partir de estos cinco aspectos.
Maven introdujo un nuevo sistema de gestión de dependencias para el mundo Java. En el mundo de Java, puede identificar de forma exclusiva una dependencia utilizando la Coordinación (coordenadas) compuesta por groupId, artifactId y version. Cualquier proyecto construido en Maven también debe definir estos tres atributos: el paquete generado puede ser un paquete Jar, un paquete de guerra o un paquete de oreja. Una referencia de dependencia típica es la siguiente:
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-test</artifactId>
</dependency>
De lo anterior se puede ver que cuando se hace referencia a una dependencia, se puede omitir la versión, de modo que se seleccionará la última versión al obtener la dependencia. Los almacenes que almacenan estos componentes se dividen en almacenes remotos y almacenes locales. El almacén remoto puede usar el almacén central común en el mundo, o puede usar Apache Nexus para construir su propio almacén privado; el almacén local está en la computadora local. A través del archivo settings.xml en el directorio de instalación de Maven, puede configurar la ruta del almacén local y la dirección del almacén remoto utilizado.
Gradle utiliza el sistema de gestión de dependencias de maven, con las siguientes diferencias:
La dependencia introducida es muy concisa.
En el mundo de Maven, hay 6 ámbitos para una dependencia, que son complie (predeterminado), provisto, tiempo de ejecución, prueba, sistema e importación. Y grade lo simplifica a 4 tipos, compilar, tiempo de ejecución, testCompile, testRuntime ???
Gradle admite dependencias de versiones dinámicas. Use el signo + después del número de versión para lograr la administración dinámica de la versión.
Construcción de módulos múltiples
Bajo la ola de SOA y microservicios, ya es una forma muy común de descomponer un proyecto en múltiples módulos. En Maven, debe definir un POM principal como un POM agregado de un grupo de módulos. Puede usar etiquetas para definir un conjunto de submódulos en el POM. El POM principal no tendrá salida de compilación real. La configuración de compilación y la configuración dependiente en el POM principal se heredan automáticamente al módulo secundario.
Y Gradle también admite la construcción de módulos múltiples. En el build.gradle de los padres, puede usar los bloques de código de todos los proyectos y subproyectos para definir si la configuración interna se aplica a todos los proyectos o subproyectos. La definición del submódulo se coloca en el archivo setttings.gradle. En el diseño de gradle, cada módulo es una instancia de objeto de Project. En el build.gradle padre, puede realizar varias operaciones en estos objetos a través de todos los proyectos o subproyectos. Esto es indudablemente más flexible que Maven.
Por ejemplo, el siguiente código está en el build.gradle del padre:
Estructura de proyecto coherente
En la era de Ant, todos crean un directorio de proyecto de Java de manera más informal, y luego usan la configuración de Ant para especificar qué pertenece a la fuente y cuáles pertenecen a testSource. El concepto de Maven al comienzo del diseño es Conversión sobre configuración (la convención es mayor que la configuración). Ha desarrollado un conjunto de estructura de directorio de proyectos como una estructura de proyecto Java estándar. Una estructura de proyecto típica de Maven es la siguiente:
Gradle también sigue esta estructura de directorio estándar. Si usa la estructura de proyecto estándar de Maven en el proyecto Gradle, entonces no hay necesidad de una configuración redundante en Gradle, solo incluya el complemento de aplicación: 'java' en el archivo, el sistema identificará automáticamente la fuente, el recurso, la secuencia de prueba, Pruebe los recursos y otros recursos correspondientes. Sin embargo, Gradle, como herramienta de compilación en JVM, también admite la construcción de códigos fuente como groovy y scala, e incluso admite la construcción mixta de lenguajes Java, groovy y scala. Aunque Maven puede lograr el mismo propósito a través de algunos complementos (como maven-scala-plugin), es obvio que Gradle es más elegante en términos de configuración.
Modelo de construcción coherente
Para resolver el problema de la falta de estandarización de las actividades de construcción de proyectos en Ant, Maven estableció específicamente un ciclo de construcción de proyecto estándar. El ciclo de construcción predeterminado es el siguiente:<phases> <phase>validate</phase> <phase>initialize</phase> <phase>generate-sources</phase> <phase>process-sources</phase> <phase>generate-resources</phase> <phase>process-resources</phase> <phase>compile</phase> <phase>process-classes</phase> <phase>generate-test-sources</phase> <phase>process-test-sources</phase> <phase>generate-test-resources</phase> <phase>process-test-resources</phase> <phase>test-compile</phase> <phase>process-test-classes</phase> <phase>test</phase> <phase>prepare-package</phase> <phase>package</phase> <phase>pre-integration-test</phase> <phase>integration-test</phase> <phase>post-integration-test</phase> <phase>verify</phase> <phase>install</phase> <phase>deploy</phase> </phases>Mecanismo de complemento
Tanto Maven como Gradle están diseñados con un mecanismo de complemento. Pero obviamente Gradle es mejor. La razón principal es que Maven está configurado en base a XML. Por lo tanto, su sintaxis de configuración es demasiado limitada a XML. Incluso la implementación de funciones muy pequeñas requiere el diseño de un complemento para establecer su asociación con la configuración XML. Por ejemplo, si desea ejecutar un comando de shell en Maven, la configuración es la siguiente:
<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <version>1.2</version> <executions> <execution> <id>drop DB => db_name</id> <phase>pre-integration-test</phase> <goals> <goal>exec</goal> </goals> <configuration> <executable>curl</executable> <arguments> <argument>-s</argument> <argument>-S</argument> <argument>-X</argument> <argument>DELETE</argument> <argument>http://${db.server}:${db.port}/db_name</argument> </arguments> </configuration> </execution> </executions> </plugin>En Gradle, todo se vuelve muy simple.
task dropDB(type: Exec) { commandLine ‘curl’,’-s’,’s’,’-x’,’DELETE’,"http://${db.server}:{db.port}/db_name" }En términos de creación de complementos personalizados, los mecanismos de Maven y Gradle son similares, ambos heredan de la clase base del complemento y luego implementan los métodos necesarios. No se dará ninguna explicación aquí.
Las principales diferencias entre Maven y Gradle se pueden ver en los cinco aspectos anteriores. La Convención sobre Configuración, el núcleo del diseño de Maven, fue promovida por Gradle, y la configuración de Gradle, es decir, el código, superó a Maven. Cualquier configuración en Gradle se puede ejecutar como código. También podemos usar el script Ant existente (la tarea Ant es un ciudadano de primera clase en Gradle), la biblioteca de clases Java y la biblioteca de clases Groovy para ayudar a escribir la tarea de construcción en cualquier momento. Este tipo de DSL implementado en su propio idioma está lleno de ejemplos de la construcción y gestión de sus propios proyectos de idiomas. Por ejemplo, Rake y Ruby, Grunt y JavaScript, Sbt y Ruby ... Y la razón por la cual Gradle usa el lenguaje Groovy es porque Groovy es más expresivo que el lenguaje Java, sus características gramaticales son más ricas y también tiene características funcionales. Los lenguajes que han surgido en los últimos años (como Scala, Go y Swift) son lenguajes fuertemente tipados y tienen características funcionales y orientadas a objetos. Finalmente, la línea de comando de Gradle es mucho más poderosa que Maven. He escrito un artículo sobre las operaciones de la línea de comandos de Gradle anteriormente. Para más detalles, vea Magia negra de la línea de comandos de Gradle
El problema
¿Qué es el alcance?
1. Enumere el significado de cada
compilación de valor de atributo , el valor predeterminado, aplicable a todas las etapas, se incluirá en el proyecto.
siempre que sea similar a la compilación, se espera que el JDK, el contenedor o el usuario proporcionen esta dependencia.
El tiempo de ejecución solo se usa en tiempo de ejecución, como el controlador JDBC, y es adecuado para la operación y las pruebas.
prueba, utilizada solo durante la prueba, para compilar y ejecutar código de prueba. No se lanzará con el proyecto.
sistema, similar al proporcionado, necesita proporcionar explícitamente un jar que contenga dependencias, Maven no lo buscará en el Repositorio
¿Cómo jugar la dependencia de la versión Gradle?
Referencia
https://www.cnblogs.com/lykbk/p/erwerwerwerwerwerwe.html
https://blog.csdn.net/zy103118/article/details/84442623
