xchart java flex maven-2 code-organization

java - xchart - ¿Pueden los proyectos de maven tener padres múltiples?



xchart date (6)

A pesar de que los proyectos de maven tienen padres solteros, pueden importar cualquier cantidad de otros pom de esta manera:

<dependencyManagement> <dependencies> <dependency> <groupId>org.example</groupId> <artifactId>my-shared-dependencies</artifactId> <version>0.0.1-SNAPSHOT</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> <dependencyManagement>

Esto tiene dos diferencias importantes en comparación con un padre:

  1. Los complementos definidos en el pom importado no se importarán
  2. Las dependencias definidas en el pom importado no se agregarán al pom actual, solo importará dependencias en la sección de administración de dependencias.

Sin embargo, si su padre pom tiene una sección de <dependencias> y desea incluirlos en sus dependencias, entonces puede agregar el padre a la sección de dependencias al igual que una dependencia regular:

<dependency> <groupId>org.example</groupId> <artifactId>my-shared-dependencies</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency>

Aunque la misma dependencia ya se ha importado, la etiqueta de la versión debe especificarse nuevamente. Para reducir la duplicación, se puede almacenar en una propiedad

Tenemos proyectos de java y flex en el trabajo. Actualmente tenemos 1 base pom que contiene las configuraciones que queremos usar para ambos proyectos. El problema con esto es: los proyectos flexibles heredan la configuración para javadoc y pmd, por ejemplo, que no desean.

Quiero hacer esto un poco más limpio y tener un verdadero base-pom y luego un java-base-pom y un flex-base-pom. Pero, ¿cómo funciona esto en un multímetro que tiene tanto una parte flexible como una parte Java?

Tenemos complementos para nuestra propia aplicación donde usamos la siguiente estructura:

  • my-plugin
    • my-plugin-client (flex)
    • my-plugin-server (java)

El my-plugin solo contiene un pom.xml con sección. Usaría my-plugin pom.xml como parent para ambos, pero tampoco puedo usar java base-pom o flex base-pom como parent. ¿Cuál sería la mejor aproximación para esto?


La única forma es tener base-pom como padre de java-base-pom y flex-base-pom.

Tengo una estructura similar para mis proyectos de primavera:

base-pom (basic configuration - eclipse, reports, repositories, etc) | + spring-base-pom (spring definitions) | + spring-jar-base-pom (jar specific definitions) | + spring-war-base-pom (spring web and servlet dependencies) | + spring-webapp-base_pom (spring web mvc dependencies)


Puede lograr herencia múltiple con perfiles:

Puede crear (múltiples) perfiles en el pom raíz y activar automáticamente cualquier variación de estos perfiles para lograr una herencia múltiple de la configuración de maven.


Solo la imagen de que pom.xml son de hecho clases de Java: puede tener solo un padre (o extiende una clase), pero este padre también puede tener otro padre, y así sucesivamente.

Como expliqué here , debe distinguir los principios primarios y de agregación en Maven, lo que significa que my-plugin se consideraría como un proyecto de agregación, no necesariamente como un proyecto principal para my-plugin-client y my-plugin-parent.

Entonces para resumir:

my-plugin definirá la base pom para todos sus proyectos. Luego, creas dos nuevos proyectos pom : java-base-pom y flex-base-pom . Tienen my-plugin como padre. Ahora, my-plugin-client tendrá java-base-pom como padre, mientras que my-plugin-server usará flex-base-pom para su padre.

De esta forma, my-plugin-client heredará todas las propiedades definidas en my-plugin pom.xml, y también en el proyecto java-base-pom .


También crucé este problema exacto, y la mejor solución que encontré fue usar Herencia y agregación como sugieren en esta pregunta: ¿admite maven múltiples padres (herencia múltiple)?

Puede tener un agregador pom que no sea el padre de los proyectos que agrega.

y explica en la Documentación de Maven

La herencia y la agregación crean una buena dinámica para controlar las compilaciones a través de un único POM de alto nivel (...) Por el contrario, un proyecto POM puede agregar proyectos que no heredan de él.

De esto obtuve la herencia de mi POM (pom-master contiene configuraciones de comunas, y cada uno de los niños las específicas):

pom-master |-- pom-java |-- pom-flex

y así mi proyecto puede obtener los detalles para cada configuración de módulos como se desee:

project (aggregate project-flex & project-java) |-- project-java | `-- pom.xml => parent = pom-java |-- project-flex | `-- pom.xml ==> parent = pom-flex `-- pom.xml => parent = pom-master

Espero que ayude a otros también :)


Un proyecto puede tener solo un padre (a diferencia de la herencia múltiple en C ++) pero este padre puede ser parte de una jerarquía principal más grande. Como señalaron otros, podría tener algo como esto:

base-pom/ |-- flex-base-pom | |-- my-plugin-client | | `-- pom.xml | `-- pom.xml |-- java-base-pom | |-- my-plugin-server | | `-- pom.xml | `-- pom.xml `-- pom.xml

Dicho esto, me di cuenta de que usted escribió que su problema real es que:

Los proyectos flexibles heredan la configuración para javadoc y pmd, por ejemplo, que no desean.

Debe usar el elemento pluginManagement para evitar esta situación:

pluginManagement es un elemento que se ve a lo largo de los complementos. La administración de complementos contiene elementos de complementos de la misma manera, excepto que en lugar de configurar la creación de complementos para esta compilación de proyecto en particular, se pretende configurar compilaciones de proyectos heredadas de esta. Sin embargo, esto solo configura los complementos a los que se hace referencia en el elemento de complementos en los elementos secundarios. Los niños tienen todo el derecho de anular las definiciones de PluginManagement.

Por lo tanto, en el pom principal, configure sus complementos en pluginManagement (javadoc y pmd, por ejemplo) y haga referencia a ellos dentro del elemento de complementos en los pluginManagement deseados (solo en my-plugin-server aquí). Esto resolvería tu problema actual.