2010-11-11 19 views
8

Nuestra empresa ha definido una serie de "mejores prácticas" con respecto a Maven poms. Por ejemplo, especificando utf-8 para el procesamiento de recursos, en qué carpetas hacer el filtrado, manejo de pruebas unitarias versus pruebas de integración y configuraciones del compilador.¿La mejor manera de compartir partes de un pom.xml de Maven en proyectos no relacionados?

En este momento, estas mejores prácticas están documentadas en la wiki de nuestra compañía, pero cuando cambia la lista de "mejores prácticas", estos cambios rara vez se reflejan en los poms del proyecto, hasta que surge un problema. La naturaleza humana es lo que es y todo ...

¿Hay alguna forma de que podamos proporcionar/hacer cumplir estas configuraciones y propiedades a través de Maven? Es casi como dar a cada proyecto un pom.xml principal, pero no quiero (ni puedo) que todos estos proyectos hagan referencia al mismo pom padre.

Necesitamos un enfoque que funcione en las máquinas del desarrollador, así como en nuestro servidor Hudson CI.

+2

leí que "porn.xml" en la otra fuente. ☺ – tchrist

Respuesta

6

La única solución de Maven es una controladora común. Quizás si usaras un padre 'liberado' podrías hacerlo?

Realice un proyecto que solo contenga el pom padre y ejecute el complemento de publicación, publicándolo en su repositorio interno. Entonces, use ese padre como padre de todos sus proyectos, haga que lo descarguen de su repositorio en lugar de encontrarlo por nombre de ruta relativo.

+0

Si entiendo correctamente, ¿no tendría que cambiar la estructura del directorio para todos los proyectos existentes? Además, estoy pensando que esto puede causar estragos en nuestro proceso de lanzamiento. Pero esta sugerencia me dio la idea de mantener al menos un pom.xml parcial bajo el control de código fuente ... – HDave

+1

SIN cambios en los directorios EN ABSOLUTO. Un padre no tiene que tener una relación de árbol del sistema de archivos. Puede ser simplemente un artefacto extraído de un repositorio. – bmargulies

+0

Hice lo que sugirió y funcionó EXCELENTE. Muchas gracias. Además del directorio mental-block, también tuve la idea equivocada (desde hace mucho tiempo) de que cualquier pom.xml que hiciera referencia a un pom padre tenía que ser nombrado como un módulo dentro de ese pom padre, es decir, los padres y los hijos tenían que ser bi- direccionalmente asociativo. – HDave

2

Sin un pom maestro, no hay una forma tecnológica de hacer cumplir lo que usted solicita (y ningún proyecto lo resolvería bien en primer lugar). La única manera efectiva de hacer cumplir las mejores prácticas a medida que evolucionan en el tiempo es haciendo que el trabajo de alguien sea hacer cumplir. Puede difundirlo entre muchas personas (por ejemplo, agregándolo a sus descripciones de trabajo), pero eso tiende a dejarlo olvidado porque todos supondrán que alguien más lo está haciendo. Una persona, identificada por su nombre, y no habrá pases.

3

Es casi como dar a cada proyecto un padre pom.xml, pero no quiero (y no puedo) que todos estos proyectos hagan referencia al mismo pom padre.

No estoy diciendo para poner necesariamente todo en un POM padres, pero en un entorno corporativo, es realmente una buena idea tener un POM corporativa de nivel superior (como se ilustra en la sección 3.6.2.2. Multi-module Enterprise Project del libro experto) , con su propio ciclo de lanzamiento.

Pero esto no será suficiente para cumplir cualquier cosa y mi sugerencia sería que mirar el Maven Enforcer Plugin que ofrece existing rules sino que también permite escribir sus propias reglas personalizadas utilizando el maven-enforcer-rule-api. Sin embargo, no puedo comentar qué tan lejos puede llegar con las reglas personalizadas. De todos modos, recomiendo este complemento. Si aún no lo está usando, es definitivamente hora de comenzar :)

+0

Haré ... gracias. – HDave

4

Puede construir el arquetipo del proyecto maven con ajustes que cumplan con las mejores prácticas de su compañía. Es más bien una solución 'proporcionar' que 'exigir' y posiblemente no sea suficiente (dependiendo de cuáles sean realmente esas mejores prácticas). http://maven.apache.org/guides/mini/guide-creating-archetypes.html

+0

Esta es una buena idea, el arquetipo podría hacer referencia a mi nuevo pom padre estandarizado ... y configurar correctamente las URL de SCM para maven-release-plugin. – HDave

4

(este es un hilo viejo, yo soy sólo añadir esta información para referencia)

para las dependencias, puede utilizar "DependencyManagement" bloque de importación (pero que va a trabajar únicamente con las dependencias y no propiedades, y así).

Solo tiene una "biblioteca" pom que define varias dependencias como siempre (con sus exclusiones y versiones específicas).

Luego, en la parte principal de su proyecto, importará esa sección de dependencia en su sección "dependencyManagement": se importarán todas las dependencias definidas en la biblioteca pom. Y, además, todas las versiones definidas en esta administración de dependencia serán siempre utilizadas por Maven (Maven no tomará otra versión distinta de la definida en la gestión de dependencias). Esto es casi obligatorio para gestionar su classpath si tiene varios proyectos que dependen del mismo conjunto de bibliotecas.

En el pom de su proyecto principal, importe el pom biblioteca de la siguiente manera:

<dependencyManagement> 
    <dependencies> 
     <dependency> 
      <groupId>com.mycompany.mylibrary</groupId> 
      <artifactId>mylibrary-artifact</artifactId> 
      <version>mylibrary-version</version> 
      <type>pom</type> 
      <scope>import</scope> 
     </dependency> 
     ... 

Comprobar online maven documentation

Cuestiones relacionadas