2010-03-24 33 views
12

OK, pensado entendí cómo utilizar Maven ...¿Cómo puedo hacer que un módulo Maven dependa de otro?

que tienen un proyecto principal M que tiene sub-proyectos A, B y C. C contiene algunas funcionalidades comunes (principalmente interfaces) que se necesitan en A y B. Puedo correr mvn compile jar:jar desde el directorio raíz del proyecto (el directorio M) y obtener archivos JAR A.jar, B.jar y C.jar. (Las versiones para todos estos artefactos son actualmente 2.0-SNAPSHOT.)

El archivo maestro pom.xml en los M listas de directorios C bajo su etiqueta <dependencyManagement>, de manera que A y B puede hacer referencia a C con sólo incluye una referencia, así:

<dependency> 
    <groupId>my.project</groupId> 
    <artifactId>C</artifactId> 
</dependency> 

Hasta ahora, muy bien. Puedo ejecutar mvn compile desde la línea de comandos y todo funciona bien. Pero cuando abro el proyecto en NetBeans, se queja del problema: "Algunos artefactos de dependencia no están en el repositorio local", y dice que el artefacto que falta es C. Del mismo modo, desde la línea de comandos, si cambio a los directorios A o B y trato de ejecutar mvn compile aparece "Error de compilación: no se pudo resolver el artefacto".

espero que podía ir manualmente a donde mi C.jar fue construido y ejecutar mvn install:install-file, pero preferiría encontrar una solución que me permite sólo trabajo directamente en NetBeans (y/o en Eclipse usando m2eclipse).

¿Qué estoy haciendo mal?

Respuesta

22

Maven se basa en el concepto de dependencias binarias y los resuelve a través del repositorio local. En otras palabras, necesita "instalar" paquetes en su repositorio local si tiene dependencias entre ellos, compilar y empaquetar código no es suficiente. Y para hacerlo, debe ejecutar install (que será instalar el paquete en el repositorio local, para usarlo como una dependencia en otros proyectos localmente).

Nota al margen: no se debe invocar mvn compile jar:jar pero prefieren mvn package.En primer lugar, al ejecutar la fase package se activarán todas las fases anteriores a package (incluidos compile) y package. Segundo, ejecutar package invocará jar:jar, o war:war, etc. dependiendo del valor <packaging> del proyecto (consulte el introduction to the lifecycle para obtener más detalles al respecto). Esa es una de las grandes fortalezas de Maven: no necesita saber si el proyecto es un JAR, un WAR, un EJB, etc. y ejecutar el objetivo apropiado para empaquetarlo. Simplemente ejecute la fase estandarizada package y Maven hará el trabajo (utilizando los enlaces de objetivos predeterminados).

Eso fue para la parte teórica de Maven. Dentro de IDEs, las cosas pueden ser ligeramente diferentes para hacer que trabajar con Maven sea más conveniente. Los IDE pueden usar dependencias de proyecto (es decir, dependencias del código dentro del IDE) en lugar de dependencias binarias para que los cambios realizados en un proyecto se hagan visibles en otros módulos sin tener que ejecutar mvn install. Este es el caso de Eclipse + M2Eclipse. Y esto se aplica también a NetBeans en las siguientes condiciones (ver Dependency Management):

Hint: If you open a project that other projects depend on, the icon in other projects changes to a "maven project" icon to denote that the IDE knows about link between the projects. However such a link is only established when the groupId, artifactId and version all match in the dependency and project declaration. Frequently occurring problem is that you change an API signature in your library project, but the application is not picking up. Often it's caused by the fact that the application is using an older version of the library artifact. The artifact icon can help you track down these problems.

+0

Gracias. En cierto modo, sabía que usar 'mvn package' en lugar de' mvn compile', pero gracias por el recordatorio. Sin embargo, el enlace "Mejores prácticas de Maven" en wiki.netbeans.org fue especialmente útil, así que estoy marcando esta respuesta como aceptada. –

+0

@Daniel De nada. Pero la nota al margen era más sobre 'mvn package' vs' mvn jar: jar' :) Me alegra que haya encontrado útil el enlace. –

+0

¿Es posible ejecutar 'install' del módulo como parte del' compile' del padre? –

6

necesita ejecutar mvn install en lugar de mvn compile. El objetivo install copiará el jar construido en el repositorio local después de compilarlo y empaquetarlo. Si solo ejecuta compilación, solo compilará los archivos de clase en el directorio target y no los pondrá a disposición de otros proyectos.

En Eclipse, si importa un pom desde el nivel superior, importará los subproyectos en proyectos de Eclipse separados y configurará las dependencias de los proyectos relacionados, luego configurará el classpath de cada proyecto para depender de los demás. No estoy familiarizado con Netbeans pero estoy bastante seguro de que hay alguna forma de hacer lo mismo.

3

netbeans vincula proyectos por el contenido del repositorio local, por lo que mvn install es necesario en la mayoría de los escenarios.

Cuestiones relacionadas