¿Tener un proyecto maven crea sus propias dependencias?

Question

Con maven, ¿es posible tener un proyecto de alto nivel cuyo tipo de empaquetado sea "de guerra" que se compilará con todos sus módulos dependientes (empaquetados como jar) y generará un archivo project.war?

Gran parte de los ejemplos de documentación y otros ejemplos que he visto a menudo usan un proyecto de nivel superior con el tipo de paquete "pom" y el proyecto solo sirve para unir los módulos. ¿Puedo evitar esto?

Así que, básicamente, necesito algo que es efectivamente como declarar un <module>my-module</module> para Maven para construir, y en ese mismo POM, declarar una <dependency>...my-module's artifact...</dependency> en ese mismo módulo que debe ser construido. Tal vez un complemento como alguien ya sugirió?

actualización: En otras palabras (para simplificar el problema): Si tengo project A y project B, donde project A depende de project B - hay una manera para mí para ejecutar una acumulación en project A y también tienen que construir de forma automática project B (e incluya project B como su dependencia - creando projectA.war que contiene projectB.jar)?

Answer 1

Para eso no es realmente un proyecto de alto nivel. Su proyecto WAR tiene dependencias, que son los artefactos (por ejemplo, jarras) que se incluirán en WAR (en WEB-INF/lib) cuando ejecuta 'paquete mvn'. Su proyecto WAR pom puede tener el proyecto de nivel superior como principal, pero no debe ser el padre de sus dependencias. Es posible que desee que ese proyecto de nivel superior sea el padre del proyecto WAR y de los proyectos JAR que son dependencias en el WAR.

Answer 2

No realmente - (Bueno, puedo pensar en un par de formas, pero no las usaría ya que son intrincadas y van en contra de los principios/prácticas básicas de Maven).

No olvide que el otro propósito del pom de nivel superior es proporcionar un único punto para establecer detalles comunes como las versiones particulares de las dependencias utilizadas en los módulos del proyecto.

Answer 3

En parent pom, debe definir un orden secuencial de los módulos que se compilarán. Puede agregar un módulo de empaque de guerra al último de esa lista. Simplemente agregará todos los códigos compilados previamente.

Answer 4

NetBeans tiene una opción que le permite hacer exactamente esto con proyectos de Maven, pero no conozco ninguna solución pura de Maven. Creo que la tarea es más adecuada para un IDE, porque sabe para qué dependían los proyectos que tiene el código (en función de los proyectos que haya abierto en el área de trabajo). ¿Cómo diferenciaría Maven a sí mismo entre una dependencia que desea construir y otra que debe obtenerse del repositorio? Y para aquellos que necesitan ser construidos, ¿dónde debería buscar el código fuente?

De todos modos, otra solución al problema, que utilicé exitosamente algunas veces, es crear un script simple que navegue a las carpetas de proyectos y comience la compilación, luego espera que termine y luego pasa al siguiente proyecto y así.

Answer 5

super_aardvark sugirió forma correcta pero,
Para el requisito que sugeriría siguiente estructura Es adecuado y buena estructura también:

Consedering ProjectA como project-webapp, ProjectB como project-core

Usted puede tener estructura siguiente :

Su gran proyecto:

<?xml version="1.0" encoding="UTF-8"?> 
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> 

    <modelVersion>4.0.0</modelVersion> 

    <groupId>com.mycompany.project</groupId> 
    <artifactId>project</artifactId> 
    <version>2.0-SNAPSHOT</version> 
    <packaging>pom</packaging> 

    <name>Project Repository System</name> 
    <description>Project Repository System R2</description> 

    <modules> 
     <module>project-core</module> 
     <module>project-webapp</module> 
    </modules> 
</project> 

su proyecto de aplicación web:

<?xml version="1.0" encoding="UTF-8"?> 
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> 
    <parent> 
     <groupId>com.mycompany.project</groupId> 
     <artifactId>project</artifactId> 
     <version>2.0-SNAPSHOT</version> 
    </parent> 
    <modelVersion>4.0.0</modelVersion> 
    <artifactId>project-webapp</artifactId> 
    <version>2.0-SNAPSHOT</version> 
    <packaging>war</packaging> 
    <name>Project Web Application</name> 
    <description>Project Repository</description> 
    <dependency> 
      <groupId>com.mycompany.project</groupId> 
      <artifactId>project-core</artifactId> 
      <version>2.0-SNAPSHOT</version> 
    </dependency> 

</project> 

su proyecto Núcleo:

<project> 
    <parent> 
     <groupId>com.mycompany.project</groupId> 
     <artifactId>project</artifactId> 
     <version>2.0-SNAPSHOT</version> 
    </parent> 
    <modelVersion>4.0.0</modelVersion> 
    <artifactId>project-core</artifactId> 
    <version>2.0-SNAPSHOT</version> 
    <packaging>jar</packaging> 
    <name>Project Core</name> 
    <description>ProjectCore</description> 

</project> 

Su estructura Directorio debe verse como:

-------Grand Parent.pom 
    | 
    |--------project-webapp 
    |      | 
    |      project-webapp.pom 
    | 
    | -------project-core.pom 
         | 
         project-core.pom 

desde POM padres ejecutar mvn clean install se va a construir tanto la aplicación web y el proyecto central

Answer 6

Esto no es posible en Maven 1, 2 o 3.

lo recomiendo a renunciar a este idea, porque todo el propósito de Maven es hacer cumplir proceso de desarrollo estandarizado. No luches contra la estructura, solo crea un módulo padre POM y crea el módulo WAR y otras dependencias debajo de él.

Answer 7

Cuando tiene un proyecto de varios módulos y está trabajando en varios módulos al mismo tiempo, puede ser tedioso y propenso a errores para asegurarse de que se actualicen todas las dependencias necesarias.

En mi situación, me gustaría que mi sistema de compilación detecte cambios y solo cree los módulos que sean necesarios. Una forma de que esto sea posible con maven es que alguien escriba un complemento personalizado que haga esto, lo cual no parece insuperable, dado que ya hay complementos complejos disponibles, como el complemento de lanzamiento Maven.

Otros ya han mencionado el concepto de agregación pom, que es repetible y produce los artefactos necesarios. Pero a veces terminas construyendo más de lo que realmente necesitas.

perfiles de Maven pueden ayudar y aquí hay un buen artículo al respecto:

Using Aggregate and Parent POMs

También tenga en cuenta en el artículo el concepto de la pom lotes, lo que no estaba previamente en cuenta.

Recuerde, mvn clean install empujará su artefacto a su repositorio local. Entonces, si el módulo A depende del módulo B, siempre que su repositorio local tenga la última compilación del módulo B, entonces debe estar todo listo. Por lo tanto, si hubiera una herramienta externa que observara los cambios en el módulo B y los construyera automáticamente cuando los hubiera y los insertará en el repositorio local, cuando el módulo A se reconstruya, retomará esos cambios.Existen herramientas de integración continua (CI) que pueden hacer esto, como Jenkins. Pero necesitaría una instalación local para tener este trabajo directamente con su repositorio local. Todavía es una opción, sin embargo.

Otra opción sería que el entorno de CI transfiera sus compilaciones a un repositorio maven externo (o incluso uno que configure localmente con algo como Nexus). Luego, configura sus compilaciones de CI para extraerlas de esa ubicación también.

Por lo tanto, existen soluciones que dependen de otras herramientas o complementos potenciales para hacer lo que desee; solo depende de cuánto tiempo y esfuerzo desee invertir para configurarlo todo. Pero, una vez que supere ese obstáculo, tendrá un sistema (y conocimiento y experiencia) que podrá usar en todos sus proyectos, sin mencionar que estará familiarizado con la cantidad de tiendas/equipos de desarrollo que trabajan.

Recomendaría investigar la integración continua y la entrega continua para obtener más información e ideas.