La diferencia entre Maven2 y maven1
En comparación con la lenta velocidad de ejecución de Maven1, Maven2 ha dado un salto cualitativo en velocidad e incluso se puede comparar con Ant (sin contar las descargas, por supuesto). Además, "Simplificar el trabajo utilizando las mejores prácticas reconocidas por la industria" es otro tema de Maven2, y otras características nuevas reflejan los esfuerzos de Maven2 por simplificar el trabajo en todas partes.
2. Menos archivos de configuración
Comparación de los principales archivos de configuración de Maven1 y Maven2;
Maven1: project.xml, maven.xml, project.properties y build.properties
Maven 2: pom.xml y settings.xml
POM es el modelo de objetos central de Maven. En Maven2, el POM se movió de project.xml a pom.xml y la versión se actualizó de 3 a 4. Para proyectos, generalmente solo se necesita pom.xml.
El uso de maven.xml no es necesario ni recomendado en Maven2 por los siguientes motivos:
Mejora la facilidad de uso del complemento.
El contenido disperso en maven.xml es difícil de compartir entre diferentes proyectos y no favorece el mantenimiento. En Maven2, se recomienda utilizar complementos personalizados para encapsular estos contenidos.
Si aún deseas poder usar funciones como maven.xml, por ejemplo
En Maven2, la configuración usa settings.xml, que reemplaza el proyecto.properties y build originales. .propiedades .
Nivel de usuario, utilizado para usuarios que inician sesión en el sistema operativo. Generalmente en $home/.m2/, para usuarios de Windows es el directorio: C:\Documentos y Configuraciones\nombre de usuario\m2\Configuraciones.
Nivel global: generalmente en %M2_HOME%/conf/settings.xml, donde M2_HOME es el nombre de la variable de entorno del directorio raíz de Maven2.
Se pueden configurar settings.xml, como repositorio local, proxy, etc. La estructura de settings.xml se puede obtener del sitio web oficial de Maven.
3. Reemplazo del lenguaje del complemento
En Maven2, el lenguaje del complemento se cambió de Jelly a Java y BeanShell. Java es más rápido y más familiar para los desarrolladores. Para otros scripts populares, como groovy y el sitio web oficial de Maven, la opinión es esperar hasta que estén más maduros.
4. Proporcionar plantillas de directorio predefinidas
Una buena estructura de directorio puede facilitar que los desarrolladores comprendan el proyecto y sentar una buena base para el mantenimiento futuro. Maven2 proporciona a los desarrolladores una plantilla de directorio estándar predeterminada basada en la mejor estructura de directorio reconocida por la industria.
El uso de plantillas de directorio puede hacer que pom.xml sea más conciso. Debido a que Maven2 tiene acciones relevantes predefinidas basadas en el directorio predeterminado, no se requiere intervención manual. Tome el directorio de recursos como ejemplo:
Src/main/resources, que es responsable de administrar los recursos del cuerpo del proyecto. Después de compilar con Maven2, todos los archivos y subdirectorios de este directorio se copiarán al directorio de destino/clases, lo que facilita el empaquetado futuro.
Src/test/resources, que se encarga de gestionar los recursos de prueba del proyecto. Después de usar Maven2 para realizar la compilación de prueba, todos los archivos y subdirectorios de este directorio se copiarán al directorio target/test-classes para prepararse para pruebas posteriores.
En Maven1, estas acciones deben usarse en maven.xml
Para crear una plantilla de directorio estándar, puede usar el siguiente comando:
mvn prototipo :create- DgroupId = com codeline . commons-darti factid = codeline commons
El significado de groupId y artefactoId es el mismo que en Maven1, y el valor del parámetro artefactoId se usará como el nombre de el directorio raíz del proyecto. Además de crear los directorios correspondientes, Maven2 también creará un pom.xml predeterminado.
Maven2 también cree que diferentes tipos de proyectos requieren diferentes estructuras de directorios. Si crea un proyecto web, puede utilizar el comando:
mvn prototipo: create-DgroupId = com mi empresa
-darti factd = mi-aplicación web
-DarchetypeArtifactId = maven-archetype-web app
5. Introducción al ciclo de vida
Maven2 tiene un concepto de ciclo de vida claro y proporciona los comandos correspondientes para hacer que la construcción del proyecto sea más eficiente. . claro. Principales fases del ciclo de vida:
Verificar que el proyecto sea correcto y que todos los recursos necesarios estén disponibles.
Compilar, compilar el código fuente del proyecto.
Prueba-compilación, compila el código de prueba del proyecto.
Prueba, utilice el código de prueba compilado para probar el código fuente compilado.
Paquete, un formato de publicación, como jar, que compila el código fuente del paquete.
Integración: pruebe, procese y publique paquetes en un entorno donde se puedan ejecutar pruebas de integración.
Verificar, realizar comprobaciones para comprobar que el paquete es válido y cumple con los estándares de calidad.
Instalar, que instala el paquete en un repositorio local y puede ser utilizado como dependencia por otros proyectos.
La implementación ejecutada en un entorno de integración o lanzamiento copia la versión final del paquete a un repositorio remoto para que otros desarrolladores o proyectos puedan usarlo.
Generate-sources, que genera cualquier código fuente adicional requerido por la aplicación, como xdoclet.
Si desea compilar un proyecto, simplemente ingrese: mvncomplete, y así sucesivamente para otras etapas. Existen dependencias entre etapas, por ejemplo, las pruebas dependen de la compilación de pruebas. Al ejecutar las pruebas de mvn, primero se ejecutará la compilación de la prueba de mvn y luego se ejecutarán las pruebas de mvn.
6. Agregar alcance de dependencia
En POM 4,
El valor predeterminado Compile se aplica a todas las etapas y se publicará con el proyecto.
Similar a compilar, siempre que se espere que el JDK, el contenedor o el usuario proporcionen esta dependencia. Por ejemplo, servlet.jar
runtime solo se usa en tiempo de ejecución, como el controlador JDBC, que es adecuado para las fases de tiempo de ejecución y prueba.
La prueba solo se utiliza durante las pruebas para compilar y ejecutar código de prueba. No se publicará con el proyecto.
De manera similar a lo proporcionado, el sistema necesita proporcionar explícitamente un contenedor que contenga la dependencia, Maven no lo buscará en el repositorio.
& ltScope>Ejemplo de uso:
<Dependencies>
& ltgroupId>Hibernation</groupId>
p>
<artifactId>hibernation</artifactid>
<version>3.0.3</version>
& ltscope>Test</scope>
</dependency>
7. gestión.
En Maven1, debe enumerar los paquetes requeridos por las dependencias. Esto es demasiado e inconveniente para los usuarios que usan algo como Hibernate. Las dependencias de transporte se implementan en Maven2, de modo que Maven2 descargará automáticamente los paquetes de los que depende Hibernate, y los desarrolladores solo deben preocuparse por Hibernate.
Nota: Solo las dependencias admitidas por Maven, generalmente en forma de complementos, pueden obtener esta función. Además, para algunos complementos antiguos, es posible que las dependencias transitivas no sean compatibles debido a limitaciones de tiempo. Por ejemplo, al menos en Maven 2.0.1, para Hibernate 2.1.2, aún necesita enumerar explícitamente los paquetes de los que depende Hibernate 2.1.2.