Referencia POM

Referencia POM
1. Introduccin
1. Cul es el POM?
2. vista rpida
2. Los basicos
1. Coordenadas Maven
2. relaciones POM
1. dependencias
1. Especificacin de requisitos de dependencia Versin
2. exclusiones
2. Herencia
1. El Super POM
2. Gestin de la dependencia
3. La agregacin (o de mltiples mdulos)
1. . La herencia v Agregacin
3. propiedades
3. Configuracin de creacin
1. Construir
1. El conjunto de elementos BaseBuild
1. recursos
2. plugins
3. Gestin Plugin
2. El Conjunto de Elementos de construccin
1. directorios
2. extensiones
2. informes
1. Conjuntos de informe
4. Ms informacin sobre el proyecto
1. licencias
2. Organizacin
3. Desarrolladores
4. colaboradores
5. Configuracin del entorno
1. Gestin de Problemas
2. Gestin de la Integracin Continua
3. Listas de correo
4. SMC
5. Requisitos previos
6. repositorios
7. repositorios de complementos
8. Gestin de la distribucin
1. Repositorio
2. Distribucin del sitio
3. reubicacin
9. perfiles
1. Activacin
2. El BaseBuild Conjunto de Elementos (revisited)
6. Final
Introduccin
El POM XSD 4.0.0 y referencia del descriptor de la documentacin
Cul es el POM?
POM significa "Proyecto de Modelo de objetos". Es una representacin XML de un
proyecto Maven celebrada en un archivo denominado pom.xml . Cuando en presencia
de gente Maven, hablando de un proyecto que se habla en el sentido filosfico, ms all
de una mera coleccin de archivos que contienen cdigo. Un proyecto contiene archivos
de configuracin, as como los desarrolladores involucrados y las funciones que
desempean, el sistema de seguimiento de defectos, la organizacin y licencias, la URL
de donde el proyecto vive, dependencias del proyecto, y todas las otras piezas
pequeas que entran en jugar para dar vida cdigo. Es una ventanilla nica para todo lo
relacionado con el proyecto. De hecho, en el mundo de Maven, un proyecto no necesita
contener ningn cdigo en absoluto, simplemente un pom.xml .
vista rpida
Esta es una lista de los elementos directamente debajo de los elementos del proyecto
del POM. Observe que modelVersion contiene 4.0.0. Esa es la versin actualmente
slo est soportado POM tanto para Maven 2 y 3, y siempre se requiere.
1. <proyecto
xmlns = "http://maven.apache.org/POM/4.0.0"
2.
xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance"
3.
xsi: schemaLocation = "http://maven.apache.org/POM/4.0.0
4.
5.
http://maven.apache.org/xsd/maven-4.0.0.xsd " >

<modelVersion> 4.0.0 </ modelVersion>
6.
7.
<! - -> Los fundamentos
8.
<groupId> ... </ groupId>
9.
<artifactId> ... </ artifactId>
10.
<versin> ... </ version>
11.
<empaque> ... </ empaque>
12.
<dependencias> ... </ dependencias>
13.
<parent> ... </ parent>
14.
<DependencyManagement> ... </ DependencyManagement>
15.
<mdulos> ... </ mdulos>
16.
<propiedades> ... </ properties>
17.
18.
<! - -> Configuracin de generacin
19.
<crear> ... </ construccin>
20.
<informes> ... </ informes>
21.
22.
<! - Ms informacin sobre el proyecto ->
23.
<nombre> ... </ name>
24.
<description> ... </ description>
25.
<url> ... </ url>
26.
<inceptionYear> ... </ inceptionYear>
27.
<licencias> ... </ licencias>
28.
<organizacin> ... </ organizacin>
29.
<desarrolladores> ... </ desarrolladores>
30.
<colaboradores> ... </ colaboradores>
31.
32.
<! - Configuracin del entorno ->
33.
<issueManagement> ... </ issueManagement>
34.
<ciManagement> ... </ ciManagement>
35.
<LISTASDECORREO> ... </ Listas de correo>
36.
<SMC> ... </ scm>
37.
<requisitos previos> ... </ requisitos previos>
38.
<repositorios> ... </ repositorios>
39.
<pluginRepositories> ... </ pluginRepositories>
40.
<distributionManagement> ... </ distributionManagement>
41.
<perfiles> ... </ perfiles>
42. </ Project>
Los basicos
El POM contiene toda la informacin necesaria acerca de un proyecto, as como las
configuraciones de los plugins que se utilizar durante el proceso de construccin.Es,
efectivamente, la manifestacin declarativa del "quin", "qu" y "dnde", mientras que el
ciclo de vida de construccin es el "cundo" y "cmo". Esto no quiere decir que el POM
no puede afectar al flujo del ciclo de vida - que puede. Por ejemplo, configurando
el experto-antRun-plugin , se puede integrar con eficacia las tareas de hormigas en el
interior del POM. En ltima instancia es una declaracin, sin embargo. Si, una
vez build.xml le dice hormiga precisamente lo que hay que hacer cuando se ejecuta
(procedimiento), un POM establece su configuracin (declarativa). Si alguna fuerza
externa hace que el ciclo de vida para omitir la ejecucin de plug-in de hormigas, no va a
detener a los plugins que se ejecutan desde hacer su magia. Esto es a diferencia de
un build.xml archivo, donde las tareas son casi siempre depende de las lneas
ejecutadas antes de que.
1. <proyecto
2.
3.
4.
5.

6.
7.
<groupId> org.codehaus.mojo </ groupId>
8.
<artifactId> mi-proyecto </ artifactId>
9.
<versin> 1.0 </ version>
10. </ Project>
Coordenadas Maven
El POM se ha definido anteriormente es el mnimo que tanto Maven 2 y 3 se lo
permita. GroupId: artifactId: Versin son todos los campos requeridos (aunque,
groupId y la versin no necesitan ser definidos de forma explcita si se heredan de un
padre - ms sobre la herencia ms adelante). Los tres campos actan tanto como una
direccin y la marca de tiempo en uno. Esto marca un lugar especfico en un repositorio,
que acta como un sistema de coordenadas para proyectos de Maven.
groupId : Esto generalmente es nico entre una organizacin o un proyecto. Por

ejemplo, todos los artefactos de ncleo Maven hacer (bueno, debe) vivir bajo el
org.apache.maven groupId. ID de grupo no utilizan necesariamente la notacin de
puntos, por ejemplo, el proyecto JUnit. Tenga en cuenta que la groupId dot-notated no
tiene que corresponder a la estructura de paquete que contiene el proyecto. Es, sin
embargo, una buena prctica a seguir. Cuando se almacena dentro de un repositorio,
el grupo acta muy parecido a la estructura de embalaje de Java hace en un sistema
operativo. Los puntos son reemplazados por utilizar separadores de directorios
especficos (tales como '/' en Unix) que se convierte en una estructura de directorios
relativa desde el repositorio de base. En el ejemplo dado, elorg.codehaus.mojo grupo
vive dentro del directorio $ M2_REPO / org / Codehaus / mojo .
artifactId : El artifactId generalmente es el nombre que el proyecto es conocido
por. Aunque el groupId es importante, las personas dentro del grupo rara vez
mencionan la groupId en la discusin (que son a menudo todo ser el mismo ID, como
el Codehaus Mojo proyecto groupId: org.codehaus.mojo ). Es, junto con el groupId,
crear una clave que separa a este proyecto de cualquier otro proyecto en el mundo (al
menos, debera :)). Junto con el groupId, el artifactId define totalmente la vivienda del
artefacto dentro del repositorio. En el caso del proyecto anterior, mi proyecto vive
en $ M2_REPO / org / Codehaus / mojo / mi-proyecto .
Versin :. Esta es la ltima pieza del rompecabezas de nombres groupId:
artifactId denotan un proyecto, pero no se puede delimitar el que la encarnacin de
ese proyecto que estamos hablando. Queremos que el junit: junit de hoy
(versin 4), o de hace cuatro aos (versin 2)? En resumen: los cambios de cdigo, los
cambios deben ser versionadas, y este elemento mantiene esas versiones en
lnea. Tambin se utiliza en el repositorio de un artefacto para separar unas de otras
versiones. Mi-proyecto de la versin 1.0 archivos viven en la estructura de
directorios $ M2_REPO / org / Codehaus / mojo / mi-proyecto / 1.0 .
Los tres elementos mencionados anteriormente apuntan a una versin especfica de

un dejar Maven proyecto sabe que nos ocupa, y cuando en su ciclo de vida del
software de las queremos.
envasado : Ahora que tenemos nuestra estructura de direccin del groupId:

artifactId: versin , hay una etiqueta estndar ms para darnos una direccin
realmente completo. Es decir tipo de artefacto del proyecto. En nuestro caso, el POM
ejemplo para org.codehaus.mojo: mi-proyecto: 1.0 definido anteriormente se
empaqueta como un tarro . Podramos convertirlo en una guerra por la que se
declara un empaquetado diferente:
1. <proyecto
2.
3.
4.
5.
...
6.
<empaque> guerra </ empaque>
7.
...
8. </ Project>
Cuando se declara ningn embalaje, Maven asume el artefacto es el valor por

defecto: tarro . Los tipos vlidos son del plexo role-pistas (lea ms en Plexus para
una explicacin de la participacin y la representacin de consejos) de la funcin
componente org.apache.maven.lifecycle.mapping.LifecycleMapping .Los
valores centrales de envasado actuales son: pom , tarro , expertoplugin , EJB , la guerra , el odo , rar , par . Estos definen la lista
predeterminada de los objetivos que se ejecutan para cada etapa del ciclo de vida
de construccin correspondiente para una estructura de paquete en particular.
Va a ver a veces la impresin de Maven a cabo coordinar un proyecto
como groupId: artifactId: embalaje: versin .
clasificador : De vez en cuando puede encontrar un quinto elemento en la

coordenada, y que es el clasificador . Vamos a visitar el clasificador ms adelante,
pero por ahora es suficiente con saber que este tipo de proyectos se muestran
como groupId: artifactId: embalaje: clasificador: versin .
relaciones POM
Un aspecto de gran alcance de Maven es en su manejo de las relaciones de los
proyectos; que incluye dependencias (y dependencias transitivas), la herencia y la
agregacin (proyectos de varios mdulos). Gestin de la dependencia tiene una larga
tradicin de ser un lo complicado para nada pero el ms trivial de los
proyectos."Jarmageddon" rpidamente sobreviene como el rbol de dependencias se
hace grande y complicado. "Jar Hell" sigue, donde las versiones de dependencias de un
sistema no son equivalentes a versiones como los desarrollados con, ya sea por la
versin incorrecta dado, o versiones en conflicto entre tarros con nombres
similares.Maven resuelve ambos problemas a travs de un repositorio local comn de

partida para proyectos de vinculacin correctamente, versiones y todos.
dependencias
La piedra angular del POM es su lista de dependencias. La mayora de cada proyecto
depende de los dems para construir y funcionar correctamente, y si todo Maven hace
por ti es administrar esta lista para usted, usted ha ganado mucho. Maven descargas y
enlaces para las dependencias que en la compilacin y otros objetivos que lo
requieran. Como un beneficio adicional, Maven trae en las dependencias de esas
dependencias (dependencias transitivas), lo que permite su lista de centrarse
nicamente en las dependencias de su proyecto requiere.
1. <proyecto
2.
3.
4.
https://maven.apache.org/xsd/maven-4.0.0.xsd " >
5.
...
6.
<dependencias>
7.
<Dependency>
8.
<groupId> JUnit </ groupId>
9.
<artifactId> JUnit </ artifactId>
10.
11.
<tipo> tarro </ type>
12.
<scope> prueba </ scope>
13.
<opcional> verdadera </ opcional>
14.
</ Dependency>
15.
...
16.
</ Dependencias>
17.
...
18. </ Project>
groupId , artifactId , versin :

Usted ver estos elementos a menudo. Esta trinidad se utiliza para calcular el Maven
de coordenadas de un proyecto especfico en el tiempo, la demarcacin como una
dependencia de este proyecto. El propsito de este clculo es seleccionar una versin
que coincide con todas las declaraciones de dependencias (debido a las dependencias
transitivas, puede haber mltiples declaraciones de dependencias para el mismo
artefacto). Los valores deben ser:
groupId , artifactId : directamente las correspondientes coordenadas de la
dependencia,
Versin : una especificacin de requisitos versin de la dependencia , que se
utilizar para calcular la versin efectiva de la dependencia.
Dado que la dependencia es descrito por las coordenadas Maven, usted puede estar
pensando: "! Esto significa que mi proyecto slo puede depender de artefactos
Maven" La respuesta es: "Por supuesto, pero eso es una buena cosa." Esto obliga a
depender nicamente de dependencias que Maven puede gestionar. Hay veces, por
desgracia, cuando un proyecto no se puede descargar desde el repositorio central
de Maven. Por ejemplo, un proyecto puede depender de un frasco que tiene una
licencia de cdigo cerrado que impide que se est en un repositorio central. Hay tres
mtodos para hacer frente a este escenario.
3. Instalar la dependencia a nivel local utilizando el plugin instalar. El mtodo es el
mtodo recomendado ms simple. Por ejemplo:
mvn instalar: instalar en archivos -dfile = no-experto-proj.jar -Dgrou
pId = some.group -DartifactId = no-experto-proj -Dversion = 1 = -Dpack
aging tarro
Tenga en cuenta que todava es necesaria una direccin, slo que esta vez se
utiliza la lnea de comandos y el plugin de instalacin crear un POM para usted
con la direccin dada.
4. Crear su propio repositorio y desplegar all. Este es un mtodo preferido para las
empresas con intranet y la necesidad de ser capaz de mantener a todos en
sincrona. Hay una meta Maven llamada despliegue: desplegar-archivo que
es similar a la instalacin: instalar-archivo meta (lea la pgina del objetivo
de la extensin para ms informacin).
5. Establecer el mbito de la dependencia del sistema y definir
un systemPath . Esto no se recomienda, sin embargo, sino que nos lleva a la
explicacin de los siguientes elementos:
clasificador :
El clasificador permite distinguir los artefactos que fueron construidas de la misma
POM, pero difieren en su contenido. Es un trozo de cuerda opcional y arbitraria que - si
est presente - se aade al nombre de artefacto justo despus del nmero de versin.
Como motivacin para este elemento, tenga en cuenta, por ejemplo, un proyecto
que ofrece un artefacto de orientacin JRE 1.5, pero al mismo tiempo tambin un
artefacto que todava apoya JRE 1.4. El primer artefacto podra estar equipado con
el clasificador jdk15 y el segundo con jdk14 de tal manera que los clientes pueden
elegir cul usar.
Otro caso de uso comn para los clasificadores es la necesidad de conectar los
artefactos secundarios a artefacto principal del proyecto. Si navega el repositorio
central de Maven, se dar cuenta de que los clasificadores de
fuentes y javadoc se utilizan para implementar el cdigo fuente del proyecto y la
documentacin de la API, junto con los archivos de clase envasados.
Tipo :
Se corresponde con el artefacto depende de envases tipo. El valor por defecto
de tarro . Si bien por lo general representa la extensin en el nombre de archivo de la
dependencia, que no siempre es el caso. Un tipo se puede asignar a una extensin
diferente y un clasificador. El tipo a menudo corresponde a los envases usados,
aunque esto tambin no es siempre el caso. Algunos ejemplos son el tarro , ejb-
cliente y la prueba de jarra . Los nuevos tipos pueden ser definidos por los plugins
que establecen las extensiones de verdad, as que esto no es una lista completa.
alcance :
Este elemento se refiere a la ruta de clase de la tarea en cuestin (compilacin y
tiempo de ejecucin, pruebas, etc.), as como la manera de limitar la transitividad de
una dependencia. Hay cinco mbitos disponibles:
compilar - este es el mbito predeterminado, utiliza si no se especifica
ninguno. Compilar dependencias estn disponibles en todas las rutas de
clases. Por otra parte, esas dependencias se propagan a proyectos dependientes.
siempre - esto es muy similar a la compilacin, sino que indica que espera el JDK
o un recipiente para proporcionar en tiempo de ejecucin. Slo est disponible en
la compilacin y prueba de ruta de clases, y no es transitiva.
tiempo de ejecucin - este mbito indica que no se requiere la dependencia para
la compilacin, pero es para su ejecucin. Es en las rutas de clases de tiempo de
ejecucin y de prueba, pero no la ruta de clase de compilacin.
prueba - este mbito indica que no se requiere la dependencia para el uso normal
de la aplicacin, y slo est disponible para las fases de compilacin y ejecucin
de pruebas. No es transitivo.
sistema - este alcance es similar al proporcionado a excepcin de que tiene que
proporcionar el archivo JAR que contiene explcitamente. El artefacto est siempre
disponible y no se busca en un repositorio.
systemPath :
se utiliza solamente si la dependencia del mbito de aplicacin es el
sistema . De lo contrario, la construccin fallar si se establece este elemento. La ruta
debe ser absoluta, por lo que se recomienda el uso de una propiedad para especificar
la ruta especfica de la mquina (ms sobre las propiedades siguientes), como $ {}
java.home / lib . Ya que se supone que las dependencias de alcance del sistema
se instalan a priori , Maven no comprobar los repositorios para el proyecto, sino que
comprueba para asegurarse de que el archivo existe. Si no es as, Maven fallar la
acumulacin y sugieren que descargar e instalar de forma manual.
opcionales :
marca opcional una dependencia cuando este proyecto en s es una
dependencia. Confuso? Por ejemplo, imagina un proyecto A , que dependa de
proyecto B para compilar una porcin de cdigo que no se puede utilizar en tiempo de
ejecucin, a continuacin, puede que no tengamos necesidad de proyecto B para todo
el proyecto. As que si el proyecto X aade proyecto Un como su propia dependencia,
entonces Maven no es necesario instalar el proyecto B en absoluto.Simblicamente,
si => representa una dependencia requerida, y -> representa opcional, aunque A =>
B puede ser el caso cuando la construccin de A X => A -> B sera el caso cuando la
construccin de X .
En los trminos ms cortos, opcional permite que otros proyectos saben que,
cuando se utiliza este proyecto, usted no necesita esta dependencia con el fin de
funcionar correctamente.
Especificacin de requisitos de dependencia Versin
Dependencias ' versin elemento de definir los requisitos de versin, que se utiliza para
calcular la versin efectiva dependencia. Requisitos de versin tienen la siguiente
sintaxis:
1.0 : Requisito de "suave" en la 1.0 (slo una recomendacin, si coincide con todos los
otros rangos de la dependencia)

[1.0] : requisito de "duro" en la 1.0
(, 1,0] : x <= 1.0
[1.2,1.3] : 1,2 <= x <= 1,3
[1.0,2.0) : 1.0 <= x <2.0
[1,5,) : x> = 1.5
(, 1,0], [1,2,) : x <= 1,0 x> = 1.2; varios conjuntos estn separados por comas
(1,1), (1,1,) : esto excluye 1.1 (por ejemplo, si se sabe que no funciona en
combinacin con esta biblioteca)
exclusiones
Exclusiones dicen explcitamente Maven que no desea incluir el proyecto especificado
que es una dependencia de esta dependencia (en otras palabras, su dependencia
transitiva). Por ejemplo, el experto-embedder requiere experto ncleos , y no quiere
usarlo o sus dependencias, a continuacin, nos gustara aadir como unaexclusin .
1. <proyecto
2.
3.
4.
5.
...
6.
<dependencias>
7.
<Dependency>
8.
<groupId> org.apache.maven </ groupId>
9.
<artifactId> maven-embedder </ artifactId>
10.
11.
<exclusiones>
12.
<Exclusin>
13.
14.
<artifactId> maven-ncleo </ artifactId>
15.
</ Exclusin>
16.
</ Exclusiones>
17.
18.
</ Dependency>
...
19.
</ Dependencias>
20.
...
21. </ Project>
A veces tambin es til para recortar dependencias transitivas de una dependencia. Una
dependencia puede haber especificado incorrectamente alcances, o dependencias que
entren en conflicto con otras dependencias en su proyecto. Usando excluye comodn
hace que sea fcil de excluir todas las dependencias transitivas de una dependencia. En
el caso de abajo usted puede estar trabajando con el experto-embedder y desea
administrar las dependencias que utiliza a s mismo, por lo que recorte todas las
dependencias transitivas:
1. <proyecto
2.
3.
4.
5.
...
6.
<dependencias>
7.
<Dependency>
8.
9.
<artifactId> maven-embedder </ artifactId>
10.
<versin> 3.1.0 </ version>
11.
<exclusiones>
12.
<Exclusin>
13.
<groupId> * </ groupId>
14.
<artifactId> * </ artifactId>
15.
</ Exclusin>
16.
</ Exclusiones>
17.
</ Dependency>
18.
...
19.
</ Dependencias>
20.
...
21. </ Project>
exclusiones : Exclusiones contienen uno o ms de exclusin elementos, que

contiene cada uno un groupId y artifactId denota una dependencia excluir. A
diferencia opcional , que puede o no ser instalado y utilizado, exclusiones eliminan
activamente desde el rbol de dependencias.
Herencia
Una adicin de gran alcance que trae Maven para construir la gestin es el concepto de
herencia proyecto. Aunque en los sistemas de compilacin como la hormiga, la herencia
sin duda puede ser simulado, Maven ha ido un paso ms en la toma de la herencia
proyecto explcita al modelo de objeto de proyecto.
1. <proyecto
2.
3.
4.
5.

6.
7.
8.
<artifactId> mi-padre </ artifactId>
9.
10.
<empaque> POM </ empaque>
11. </ Project>
El envasado tipo requerido para ser pom de los padres y de agregacin de proyectos
(varios mdulos). Estos tipos definen los objetivos unidos a un conjunto de etapas del
ciclo de vida. Por ejemplo, si el envase es frasco , entonces el paquete de fase se
ejecutar el tarro: Tarro de meta. Si el envase es pom , el objetivo ser
ejecutada sitio: attach-descriptor . Ahora podemos aadir valores a la matriz
POM, que ser heredado por sus hijos. Los elementos de la matriz POM que son
heredados por sus hijos son:
dependencias
desarrolladores y colaboradores
listas de plugin
listas de informes
ejecuciones de complementos con los identificadores de bsqueda
configuracin del plugin
1. <proyecto
2.
3.
4.
5.

6.
7.
<Parent>
8.
9.
10.
11.
<relativePath> ../my-parent </ relativePath>
12.
</ Parent>
13.
14.
15. </ Project>
Ntese la relativePath elemento. No es necesario, pero puede ser utilizado como un

significante de Maven para buscar primero la ruta dada por los padres de este proyecto,
antes de buscar en los repositorios locales y remotos.
Para ver la herencia en la accin, simplemente echar un vistazo a
la ASF o Maven matriz de POM.
El Super POM
Al igual que en la herencia de los objetos en la programacin orientada a objetos, que se
extienden POM POM uno de los padres heredan ciertos valores de ese padre.Adems,
as como objetos Java en ltima instancia hereda de java.lang.Object , todos los

modelos de proyectos de objetos heredan de una base de Super POM. El siguiente
fragmento es el Super POM para Maven 3.0.4.
1. <Proyecto>
2.
3.
4.
<repositorios>
5.
<Repositorio>
6.
<id> Central </ id>
7.
<nombre> Repositorio Central </ name>
8.
<url> http://repo.maven.apache.org/maven2 </ url>
9.
<layout> default </ layout>
10.
<Instantneas>
11.
<enabled> false </ enabled>
12.
</ Instantneas>
13.
</ Repositorio>
14.
</ Repositorios>
15.
16.
<PluginRepositories>
17.
<PluginRepository>
18.
<id> Central </ id>
19.
<nombre> Repositorio Central </ name>
20.
<url> http://repo.maven.apache.org/maven2 </ url>
21.
22.
<Instantneas>
23.
24.
</ Instantneas>
25.
<comunicados>
26.
<updatePolicy> no </ updatePolicy>
27.
</ Prensa>
28.
</ PluginRepository>
29.
</ PluginRepositories>
30.
31.
<Crear>
32.
<directorio> $ {} project.basedir / destino </ Directory>
33.
<OutputDirectory> $ {} project.build.directory / clases </ OutputDire

ctory>
34.
<finalName> $ {} project.artifactId - $ {} project.version </ finalNa

me>
35.
<testOutputDirectory> $ {} project.build.directory / test-clases </ t

estOutputDirectory>
36.
<sourceDirectory> $ {} project.basedir / src / main / java </ sourceD

irectory>
37.
<scriptSourceDirectory> src / main / scripts </ scriptSourceDirectory

>
38.
<testSourceDirectory> $ {} project.basedir / src / test / java </ tes

tSourceDirectory>
39.
<recursos>
40.
<Resource>
41.
<directorio> $ {} project.basedir / src / main / resources </ Dir

ectory>
42.
</ Resource>
43.
</ Recursos>
44.
<TestResources>
45.
<TestResource>
46.
<directorio> $ {} project.basedir / src / test / recursos </ Dire

ctory>
47.
</ TestResource>
48.
</ TestResources>
49.
<PluginManagement>
50.
<! - NOTA: Estos plugins sern retirados de las futuras versiones d

el POM sper ->
51.
<! - Se mantienen por el momento ya que son muy poco probable que e
l conflicto con las asignaciones del ciclo de vida (MNG-4453) ->
52.
<Plugins>
53.
<Plug-in>
54.
<artifactId> maven-antRun-plugin </ artifactId>
55.
56.
</ Plugin>
57.
<Plug-in>
58.
<artifactId> maven-plugin-ensamblaje </ artifactId>
59.
<versin> 2.2-beta-5 </ version>
60.
</ Plugin>
61.
<Plug-in>
62.
<artifactId> maven-dependencia-plugin </ artifactId>
63.
64.
</ Plugin>
65.
<Plug-in>
66.
<artifactId> maven-plugin de liberacin </ artifactId>
67.
68.
</ Plugin>
69.
70.
71.
</ Plugins>
</ PluginManagement>
</ Construccin>
72.
73.
74.
<Informes>
<OutputDirectory> $ {} project.build.directory / sitio </ OutputDirec
tory>
75.
</ Informes>
76.
77.
<Perfiles>
78.
<! - NOTA: El perfil de liberacin ser retirado de las futuras versi

ones del POM sper ->
79.
80.
<Perfil>
<id> liberar perfil </ id>
81.
82.
83.
<Activacin>
<Propiedad>
84.
<nombre> performRelease </ name>
85.
<valor> verdadera </ value>
86.
</ Property>
87.
</ Activacin>
88.
89.
90.
91.
<Crear>
<Plugins>
<Plug-in>
92.
<heredada> verdadera </ heredada>
93.
<artifactId> maven-fuente-plugin </ artifactId>
94.
<ejecuciones>
95.
<Ejecucin>
96.
<ID> adjuntar-sources </ id>
97.
<objetivos>
98.
99.
<meta> tarro </ meta>

</ Objetivos>
100.
</ Ejecucin>
101.
</ Ejecuciones>
102.
</ Plugin>
103.
<Plug-in>
104.
105.
<artifactId> maven-javadoc-plugin </ artifactId>
106.
<ejecuciones>
107.
<Ejecucin>
108.
<ID> attach-javadocs </ id>
109.
<objetivos>
110.
111.

</ Objetivos>
112.
</ Ejecucin>
113.
</ Ejecuciones>
114.
</ Plugin>
115.
<Plug-in>
116.
117.
<artifactId> maven-plugin de implementar </ artifactId>
118.
<Configuration>
119.
120.
121.
122.
<updateReleaseInfo> verdadera </ updateReleaseInfo>

</ Configuration>
</ Plugin>
</ Plugins>
123.
124.
125.
</ Construccin>
</ Profile>
</ Perfiles>
126.
127.
</ Project>
Puede echar un vistazo a cmo el Sper POM afecta a su proyecto de modelo de

objetos mediante la creacin de un mnimo pom.xml y ejecutar en la lnea de
comandos: ayuda mvn: efectivo-pom
Gestin de la dependencia
Adems de heredar ciertos elementos de nivel superior, los padres tienen elementos
para configurar los valores de los POM nio y dependencias transitivas. Uno de esos
elementos es DependencyManagement .
DependencyManagement : es utilizado por los POM para ayudar a manejar la

informacin de dependencia a travs de todos sus hijos. Si el mi-padre proyecto
utiliza DependencyManagement para definir una dependencia de junit: junit: 4.0 ,
a continuacin, los POM que hereda de ste puede establecer su dependencia dando
la groupId = junit y artifactId = junit solamente, entonces Maven llenar en
el versin establecida por el padre. Los beneficios de este mtodo son
evidentes. Detalles de dependencia se pueden establecer en una ubicacin central,
que se propagar a todos los POM que heredan.
Tenga en cuenta que la versin y el alcance de los artefactos que se incorporan de
dependencias transitivas tambin son controlados por especificaciones de la versin
de una seccin de gestin de la dependencia. Esto puede conducir a consecuencias
inesperadas. Consideremos un caso en el que el proyecto utiliza dos
dependencias, DEP1 y DEP2 . DEP2 a su vez tambin utiliza DEP1 , y requiere una
versin mnima determinada para funcionar. Si a continuacin,
utilizaDependencyManagement para especificar una versin ms antigua, DEP2 se
ver obligado a utilizar la versin anterior, y no. Por lo tanto, debe tener cuidado de
comprobar todo el rbol de dependencias para evitar este problema, la
dependencia mvn: rbol es til.
La agregacin (o de mltiples mdulos)

Un proyecto con mdulos se conoce como un multimdulo, o proyecto agregador. Los
mdulos son los proyectos que enumera este POM, y se ejecutan como un
grupo.Un pom proyecto de envasado puede agregar la acumulacin de un conjunto de
proyectos, mediante su inclusin como mdulos, que son directorios relativos a esos
proyectos.
1. <proyecto
2.
3.
4.
5.
6.
7.
8.
9.
10.
<empaque> POM </ empaque>
11.
12.
<mdulos>
13.
<mdulo> mi-proyecto </ modulo>
14.
<mdulo> otro proyecto </ modulo>
15.
</ Mdulos>
16. </ Project>
No es necesario tener en cuenta la interrelacin de dependencias de mdulos a s

mismo cuando se enumeran los mdulos, es decir, el orden de los mdulos propuestos
por el POM no es importante. Maven topolgicamente clasificar los mdulos de tal
manera que siempre se construyen dependencias antes de los mdulos dependientes.
Para ver la agregacin en accin, slo echar un vistazo en el Maven o Maven Core
plugins POM de base de.
Una nota final sobre la herencia v . Agregacin
La herencia y agregacin crean un agradable dinmico para controlar construye a travs
de una sola, POM de alto nivel. Es frecuente encontrar que los proyectos que son los
padres y los agregadores. Por ejemplo, todo el ncleo experto corre a travs de una
nica base de POM org.apache.maven: experto , por lo que la construccin del
proyecto Maven puede ser ejecutado por un solo comando: compilacin MVN . Sin
embargo, aunque ambos proyectos POM, un proyecto agregador y un proyecto de
matriz no son uno en el mismo y no deben confundirse. Un proyecto POM puede ser
heredada de - pero no necesariamente - los mdulos que agregados. Por el contrario, un
proyecto POM puede agregar proyectos que no heredan de ella.
propiedades
Las propiedades son la ltima pieza necesaria en la comprensin de conceptos bsicos
POM. Maven propiedades son el valor del marcador de posicin, al igual que las
propiedades de la hormiga. Sus valores son accesibles en cualquier lugar dentro de un
POM mediante el uso de la notacin $ {X} , donde X es la propiedad.
Vienen en cinco estilos diferentes:
1. env.X : prefijar una variable con "env". volver variable de entorno de la cscara. Por
ejemplo, $ {} env.PATH contiene la variable de entorno PATH.
Nota: Mientras que las variables de entorno en s son sensibles a maysculas en
Windows, las operaciones de bsqueda de propiedades entre maysculas y
minsculas. En otras palabras, mientras que el shell de Windows devuelve el mismo
valor para % PATH% y % Path% , Maven distingue entre $ {} env.PATH y $ {}

env.Path . A partir de Maven 2.1.0, los nombres de las variables de entorno se
normalizan a toda mayscula en aras de la fiabilidad.
2. project.x : (.) Un punto ruta anotada en el POM contendr el valor del elemento
correspondiente. Por ejemplo: <proyecto> <versin> 1.0 </ version> </
project> es accesible a travs de $ {} project.version .
3. settings.x : (.) Un punto ruta anotada en el settings.xml contendr el valor del
elemento correspondiente. Por ejemplo: <parmetros> <offline> false </ fuera
de lnea> </ settings> es accesible a travs de $ {} settings.offline .
4. Propiedades del sistema Java: Todas las propiedades accesibles a travs
de java.lang.System.getProperties () estn disponibles como propiedades POM,
como $ {} java.home .
5. x : Ubicado en un <propiedades /> elemento en el POM. El valor de <properties>
<somevar> valor </ somevar> </ Properies> puede ser utilizado como $ {}
somevar .
Configuracin de creacin
Ms all de los conceptos bsicos del POM dado anteriormente, hay dos elementos ms
que deben ser entendidos antes de reclamar la competencia bsica del POM.Son
la acumulacin elemento, que se ocupa de cosas como la que se declara la estructura
de directorios de su proyecto y la gestin de plugins; y la presentacin de
informes elemento, que refleja en gran medida el elemento de construccin para los
informes.
Construir
De acuerdo con el XSD 4.0.0 POM, la acumulacin elemento se divide
conceptualmente en dos partes: hay una BaseBuild tipo que contiene el conjunto de
elementos comunes a ambos construir elementos (el elemento de construccin de alto
nivel bajo proyecto y el elemento de estructura inferior perfiles , cubierto a
continuacin); y no es el Build tipo, que contiene el BaseBuild establecido, as como
ms elementos para la definicin de nivel superior. Vamos a empezar con un anlisis de
los elementos comunes entre los dos.
Nota: Estos diferentes build elementos pueden denotarse "generacin de proyecto" y
"acumulacin perfil".
1. <proyecto
2.
3.
4.
5.
...
6.
<! - "Build Project" contiene ms elementos que slo el conjunto BaseBu

ild ->
7.
8.
9.
<Perfiles>
10.
<Perfil>
11.
<! - "Perfil Build" contiene un subconjunto de elementos "Build Pro

ject" s ->
12.
13.
</ Profile>
14.
</ Perfiles>
15. </ Project>
El elemento BaseBuild Conjunto

BaseBuild es exactamente como suena: el conjunto bsico de elementos entre las
dos acumulaciones elementos en el POM.

<Crear>
<DefaultGoal> instalar </ defaultGoal>
<Directorio> $ {} basedir / destino </ Directory>
<FinalName> $ {} artifactId - $ {version} </ finalName>
<filtros>
<Filtro> filtros / filter1.properties </ filter>
</ Filtros>
...
</ Construccin>
defaultGoal : el objetivo predeterminado o fase de ejecutar si no se da ninguno. Si se

da una meta, es necesario definir lo que est en la lnea de comandos (como eltarro:
Tarro ). Lo mismo ocurre con si una fase est definida (como instalar).
Directorio : Este es el directorio donde la acumulacin volcar sus archivos o, en la
jerga de Maven, el objetivo de la construccin. Acertadamente por defecto $ {}
basedir / diana .
finalName : Este es el nombre del proyecto liado cuando finalmente se construy
(sans la extensin del archivo, por ejemplo: mi-proyecto-1.0.jar ). Su valor
predeterminado es $ {} artifactId - $ {version} . El trmino "finalName" es una
especie de un trmino equivocado, sin embargo, como plugins que construyen el
proyecto liado tienen todo el derecho a ignorar / modificar este nombre (pero por lo
general no lo hacen). Por ejemplo, si el experto-jar-plugin est configurado para
dar un frasco de un clasificador de prueba , entonces el frasco real se ha definido
anteriormente se construir como mi-proyecto-1,0-test.jar .
Filtro : Define * .properties archivos que contienen una lista de propiedades que se
aplican a los recursos que acepten sus ajustes (cubiertas ms abajo). En otras
palabras, el " nombre = valor " pares definidos dentro de los archivos de filtro
sustituir $ {name} cuerdas dentro de los recursos en la construccin. El ejemplo

anterior define el filter1.properties de archivos bajo el filtro
/ directorio. Directorio de filtro predeterminado de Maven es $ {} basedir / src /
main / filtros / .
Para un anlisis ms completo de lo que los filtros son y lo que pueden hacer, echar
un vistazo a la gua de inicio rpido .
recursos
Otra caracterstica de construir elementos est especificando en que existen recursos
dentro de su proyecto. Los recursos no son de cdigo (por lo general). Ellos no se
compilan, pero estn destinados a ser incluido dentro de su proyecto o el programa
usado por varias otras razones, tales como la generacin de cdigo de los artculos.
Por ejemplo, un proyecto requiere un plexo configuration.xml archivo (que especifica
configuraciones de componentes al contenedor) para vivir dentro de la / del plexo
META-INF directorio. Aunque pudiramos colocar fcilmente dentro de este archivo src
/ main / recurso / META-INF / plexo , queremos dar lugar a Plexus su propio
directorio del src / main / plexo . Para que el plugin JAR para empaquetar el recurso
correctamente, debe especificar los recursos similares a los siguientes:
1. <proyecto
2.
3.
4.
5.
<Crear>
6.
...
7.
<recursos>
8.
<Resource>
9.
<targetPath> META-INF / plexo </ targetPath>
10.
<filtrado> false </ filtrado>
11.
<directorio> $ {} basedir / src / main / plexo </ Directory>
12.
<Incluye>
13.
<include> configuration.xml </ include>
14.
</ Includes>
15.
<excluye>
16.
<exclude> ** / *. propiedades </ exclude>
17.
18.
</ Excluye>
</ Resource>
19.
</ Recursos>
20.
<TestResources>
21.
...
22.
</ TestResources>
23.
...
24.
</ Construccin>
25. </ Project>
recursos : es una lista de los elementos de los recursos que describen cada uno qu y
dnde para incluir ficheros asociados a este proyecto.
targetPath : especifica la estructura de directorios para colocar el conjunto de recursos
de la que se acumulan. Orientar los valores predeterminados ruta de acceso al
directorio base. Una ruta de destino comnmente especificada por los recursos que
sern envasados en un frasco es META-INF.
Filtrado : es verdadera o falsa , denotando si el filtrado es para estar habilitado para
este recurso. Tenga en cuenta, que filtran * .properties archivos no tienen que ser
definidos para el filtrado de ocurrir - recursos tambin pueden utilizar las propiedades
que estn por defecto definido en el POM (por ejemplo, $ {} project.version), aprobada
en la lnea de comandos utilizando el bandera "D" (por ejemplo, " -dNOMBRE = valor ")
o se definen de manera explcita por el elemento de propiedades. Filtrar archivos
estaban cubiertas anteriormente.
directorio : el valor de este elemento define el lugar donde se encuentran los
recursos. El directorio por defecto para una generacin es $ {} basedir / src /
main / resources .
incluye : un conjunto de archivos patrones que especifican los archivos para incluir
como recursos correspondientes a ese directorio especificado, utilizando * como un
comodn.
excluye : La misma estructura que incluye , pero Especifica los archivos de
ignorar. En los conflictos entre incluir y excluir , excluir victorias.
testResources : El testResources bloque elemento
contiene testResource elementos. Sus definiciones son similares a los
recursos elementos, pero se utilizan de forma natural durante las fases de prueba. La
nica diferencia es que el directorio de recursos de prueba predeterminado (Super
POM definido) para un proyecto es $ {} basedir / src / test / recursos . Los
recursos de pruebas no se implementan.
plugins
1. <proyecto
2.
3.
4.
5.
<Crear>
6.
...
7.
<Plugins>
8.
<Plug-in>
9.
<groupId> org.apache.maven.plugins </ groupId>
10.
<artifactId> maven-jar-plugin </ artifactId>
11.
12.
<extensiones> false </ extensiones>
13.
14.
<Configuration>
15.
16.
<clasificador> prueba </ clasificador>

</ Configuration>
17.
18.
<ejecuciones> ... </ ejecuciones>
19.
</ Plugin>
20.
</ Plugins>
21.
</ Construccin>
22. </ Project>
Ms all de la norma de coordenadas de groupId: artifactId: versin , hay

elementos que configuran el plugin o esto construye la interaccin con l.
extensiones : verdaderas o falsas , ya sea o no para cargar las extensiones de este

plugin. Es por falsa predeterminado. Las extensiones se tratan ms adelante en este
documento.
hered : verdadero o falso , si esta configuracin del plugin debe aplicarse a los
POM, que heredan de ste. El valor por defecto es cierto .
configuracin : Esto es especfico para el plugin individual. Sin ir ms a fondo en la
mecnica de cmo funcionan los plugins, basta con decir que todo lo que el plugin
propiedades Mojo puede esperar (estos son los captadores y definidores en el bean
Java Mojo) se puede especificar aqu. En el ejemplo anterior, estamos estableciendo la
propiedad clasificador para probar en el experto-jar-plugin Mojo 's. Puede ser
bueno tener en cuenta que todos los elementos de configuracin, donde quiera que se
encuentren dentro del POM, tienen la intencin de pasar valores a otro sistema
subyacente, como un plugin. En otras palabras: los valores dentro de
una configuracin de elemento no se requiere explcitamente por el esquema de
POM, pero un gol plugin tiene todo el derecho a exigir los valores de configuracin.
Si el POM declara un padre, heredar la configuracin del complemento de
cualquiera de las build / plugins o pluginManagement secciones de la matriz.
Como ejemplo, consideremos el siguiente fragmento de un POM padres:
1. <Plug-in>
2. <groupId> my.group </ groupId>
3. <artifactId> mi-plugin </ artifactId>
4. <Configuration>
5.
6.
7.
<Elementos>
<item> padre-1 </ item>
8.
</ Items>
9.
<propiedades>
10.
11.
<parentKey> padres </ parentKey>

</ Properties>
12. </ Configuration>

13. </ Plugin>
Y considerar la siguiente configuracin del complemento de un proyecto que utiliza

ese padre como su padre:
14. <Plug-in>
17. <Configuration>
18.
19.
<Elementos>
<item> nio-1 </ item>
20.
</ Items>
21.
<propiedades>
22.
23.
<childKey> nio </ childKey>

</ Properties>
El comportamiento por defecto es la de integrar el contenido de la configuracin

del elemento de acuerdo a nombre del elemento. Si el nio POM tiene un elemento
en particular, que el valor se convierte en el valor efectivo. si el nio POM no tiene
un elemento, pero el padre lo hace, el valor de los padres se convierte en el valor
efectivo. Tenga en cuenta que esto es puramente una operacin en XML; ningn
cdigo o configuracin del propio plugin est involucrado. Slo los elementos, no sus
valores, estn involucrados.
La aplicacin de estas reglas para el ejemplo, Maven viene con:
25. <Plug-in>
28. <Configuration>
29.
30.
<Elementos>
31.
</ Items>
32.
<propiedades>
33.
34.
<parentKey> padres </ parentKey>
35.
</ Properties>
Puede controlar cmo los POM secundarios heredan la configuracin a los POM
principal aadiendo atributos a los hijos de la configuracin del elemento. Los
atributos son combine.children y combine.self . Use estos atributos en un POM
nio para controlar la forma en Maven combina plugin de la configuracin de la
matriz con la configuracin explcita en el nio.
Esta es la configuracin de los nios con ilustraciones de los dos atributos:
37. <Configuration>
38.
<elementos
se combinan . hijos = "Agregar" >
39.
<! - Combine.children = "fusionar" es el valor por defecto ->
40.
41.
</ Items>
42.
<propiedades
se combinan . auto = "anular" >
43.
<! - Combine.self = "fusionar" es el valor por defecto ->
44.
45.
</ Properties>
Ahora, el resultado efectivo es el siguiente:

47. <Configuration>
48.
<elementos
se combinan . hijos = "Agregar" >
49.
50.
51.
52.
</ Items>
53.
<propiedades
54.
55.
se combinan . auto = "anular" >

</ Properties>
combine.children = "Aadir" da como resultado la concatenacin de elementos

primarios y secundarios, en ese orden. combine.self = "override" , por otro lado,
suprime por completo la configuracin de los padres. No se puede utilizar tanto en
tanto combine.self = "anular" y combine.children = "aadir" en un elemento;si se
intenta, anulacin prevalecer.
Tenga en cuenta que estos atributos slo se aplican al elemento de configuracin
que se declaran en, y no se propagan a los elementos anidados. Esto es, si el
contenido de un elemento elemento del nio POM era una estructura compleja en
lugar de texto, sus sub-elementos tambin estara sujeto a la estrategia de
combinacin por defecto a menos que ellos mismos eran marcados con atributos.
Los atributos se combinan. * Se heredan de padres a los POM nio. Tenga cuidado
al aadir los atributos de un POM padres ya que esto podra afectar a los nios o de
cola en el nio POM.
Dependencias : Las dependencias se ven mucho en el POM, y son un elemento en

virtud de todos los bloques de elementos de plugins. Las dependencias tienen la
misma estructura y funcin que en virtud de dicha construccin base. La principal
diferencia en este caso es que en lugar de aplicar como dependencias del proyecto,
que ahora se aplican como dependencias del plugin que estn bajo. El poder de esta
funcin es modificar la lista de dependencias de un plugin, tal vez mediante la
eliminacin de una dependencia de tiempo de ejecucin no usado a
travs exclusiones , o mediante la alteracin de la versin de un dpendency

requerido. Vase el epgrafe Dependencias para ms informacin.
ejecuciones : Es importante tener en cuenta que un plugin puede tener varios
objetivos. Cada meta puede tener una configuracin separada, posiblemente, incluso
la unin meta de un plugin para una fase diferente en
conjunto. Ejecuciones configurar la ejecucin de los objetivos de un plugin.
Por ejemplo, suponga que desea vincular a la antRun: correr peligro
al verificar fase. Queremos que la tarea de echo el directorio de construccin, as
como evitar la transmisin de esta configuracin a sus hijos (asumiendo que es un
padre) estableciendo heredada de falsa . Se podra obtener una ejecucin de la
siguiente manera:
1. <proyecto
2.
3.
4.
5.
...
6.
<Crear>
7.
<Plugins>
8.
<Plug-in>
9.
<artifactId> maven-antRun-plugin </ artifactId>
10.
11.
<ejecuciones>
12.
<Ejecucin>
13.
<id> echodir </ id>
14.
<objetivos>
15.
<meta> ejecutar </ meta>
16.
</ Objetivos>
17.
<fase> verificar </ fase>
18.
<heredada> false </ heredada>
19.
<Configuration>
20.
<tareas>
21.
<eco> Construir Dir: $ {} project.build.directory </ e

cho>
22.
</ tareas>
23.
</ Configuration>
24.
</ Ejecucin>
25.
</ Ejecuciones>
26.
27.
</ Plugin>
28.
</ Plugins>
29.
</ Construccin>
30. </ Project>
ID : explica por s misma. En l se especifica este bloque de ejecucin entre todos los
dems. Cuando se ejecuta la fase, que se mostrar en la forma: [plugin: meta de
ejecucin: id ] . En el caso de este ejemplo: [antRun: ejecutar de ejecucin:

echodir ]
objetivos : Al igual que todos los elementos POM pluralizado, este contiene una lista
de elementos singulares. En este caso, una lista de los plugins objetivos que estn
siendo establecidas en la presente ejecucin bloque.
fase : Esta es la fase que la lista de objetivos se ejecutar en Esta es una opcin muy
potente, que permite una para obligar a cualquier meta a cualquier fase del ciclo de
vida de construccin, alterando el comportamiento predeterminado de Maven..
heredada : Al igual que la heredada elemento anterior, el establecimiento de esta
falsa ser suprimir Maven desde la aprobacin de esta ejecucin a sus hijos. Este
elemento slo tiene sentido para los POM padres.
Configuracin : Igual que el anterior, pero se limita a la configuracin de esta lista
especfica de objetivos, en lugar de todos los objetivos en el marco del plugin.
Gestin Plugin
pluginManagement : es un elemento que se ve a lo largo plugins

secundarios. Gestin Plugin contiene elementos de plugin en la misma forma, excepto
que en lugar de configurar plugin de informacin para este particular, generacin de
proyecto, se pretende configurar proyecto se basa en que hereda de ste. Sin
embargo, esto slo se configura plugins que en realidad se hace referencia en el
elemento de plugins en los nios. Los nios tienen todo el derecho de
anular pluginManagementdefiniciones.
1. <proyecto
2.
3.
4.
5.
...
6.
<Crear>
7.
...
8.
<PluginManagement>
9.
10.
<Plugins>
<Plug-in>
11.
12.
13.
14.
<ejecuciones>
15.
<Ejecucin>
16.
<ID> pre-proceso-clases </ id>
17.
<fase> compilacin </ fase>
18.
<objetivos>
19.
20.
</ Objetivos>
21.
<Configuration>
22.
<clasificador> pre-proceso </ clasificador>
23.
</ Configuration>
24.
</ Ejecucin>
25.
</ Ejecuciones>
26.
</ Plugin>
27.
</ Plugins>
28.
</ PluginManagement>
29.
...
30.
</ Construccin>
31. </ Project>
Si aadimos a estas especificaciones el elemento de plugins, que se aplicaran

nicamente a un solo POM. Sin embargo, si las aplicamos bajo
la pluginManagementelemento, entonces este POM y todos los POM heredan que
aaden el experto-jar-plugin a la acumulacin obtendrn el pre-procesoclases de ejecucin as.As que ms que el desorden por encima de todos los nios
incluidos en pom.xml , solamente se requiere lo siguiente:
1. <proyecto
2.
3.
4.
5.
...
6.
<Crear>
7.
...
8.
<Plugins>
9.
<Plug-in>
10.
11.
12.
13.
14.
15.
</ Plugin>
</ Plugins>
...
</ Construccin>
16. </ Project>
La construccin de elementos Conjunto

La construccin tipo en el XSD denota aquellos elementos que estn disponibles slo
para la "generacin de proyecto". A pesar del nmero de elementos adicionales (seis),
en realidad slo hay dos grupos de elementos que contiene proyecto de construccin
que faltan en la acumulacin perfil: directorios y extensiones.
directorios
El conjunto de elementos de directorio viven en el elemento de generacin de primario,
que establece diversas estructuras de directorio para el POM en su conjunto.Puesto que
no existen en el perfil se basa, estos no pueden ser alterados por perfiles.
1. <proyecto
2.
3.
4.
5.
...
6.
<Crear>
7.
<sourceDirectory> $ {} basedir / src / main / java </ sourceDirectory

>
8.
<scriptSourceDirectory> $ {} basedir / src / main / scripts </ script

SourceDirectory>
9.
<testSourceDirectory> $ {} basedir / src / test / java </ testSourceD

irectory>
10.
<OutputDirectory> $ {} basedir / target / classes </ OutputDirectory>
11.
<testOutputDirectory> $ {} basedir / target / test-clases </ testOutp

utDirectory>
12.
13.
...
</ Construccin>
14. </ Project>
Si los valores de a * Directorio elemento anterior se ha configurado como una ruta

absoluta (cuando sus propiedades son expandidas) a continuacin, se utiliza ese
directorio. De lo contrario, es relativa al directorio de generacin de base: $ {}
basedir .
extensiones
Las extensiones son una lista de objetos que se van a utilizar en esta construccin. Ellos
sern incluidos en la ruta de clase de construccin en marcha. Se pueden habilitar
extensiones al proceso de construccin (tales como agregar un proveedor de ftp para el
mecanismo de transporte del carro), as como hacer plugins activos que hacen que los
cambios en el ciclo de vida de construccin. En resumen, las extensiones son artefactos
que activan durante la compilacin. Las extensiones no tienen que hacer nada en
realidad, ni contienen una Mojo. Por esta razn, las extensiones son excelentes para
especificar uno de mltiples implementaciones de una interfaz de complementos comn.
1. <proyecto
2.
3.
4.
5.
...
6.
<Crear>
7.
...
8.
<extensiones>
9.
<Extensin>
10.
<groupId> org.apache.maven.wagon </ groupId>
11.
<artifactId> vagn-ftp </ artifactId>
12.
<versin> 1.0-alfa-3 </ version>
13.
</ Extension>
14.
</ Extensiones>
15.
...
16.
</ Construccin>
17. </ Project>
informes
Reporting contiene los elementos que corresponden especficamente para el sitio
de fase de generacin. Ciertos plugins de Maven pueden generar informes definidos y
configurados bajo el elemento de informes, por ejemplo: la generacin de informes
Javadoc. Al igual que la capacidad del elemento de construccin para configurar los
plugins, la presentacin de informes comandos de la misma capacidad. La evidente
diferencia es que en lugar de un control detallado de los plug-in de objetivos dentro de
las ejecuciones bloquear, informes configura objetivos dentro reportSet elementos. Y la
diferencia sutil que es un plugin de configuracin bajo la presentacin de
informes elemento funciona como acumulacin plugin de configuracin , aunque el
contrario no es cierto (una acumulacin plugin deconfiguracin no afecta a
la presentacin de informes plug-in).
Posiblemente el nico elemento en la presentacin de informes elemento que no
sera familiar para alguien que entiende la acumulacin elemento es el
booleanas excludeDefaults elemento. Este elemento indica al generador de sitios para
excluir informes generados normalmente por defecto. Cuando un sitio se genera a travs
del sitio de ciclo de acumulacin, una Informacin del Proyecto seccin se coloca en
el men de la izquierda, hasta los topes de informes, tales como el Equipo de Proyecto
de informe o Dependencias informe de lista. Estos objetivos del informe son generados
por maven-proyecto-info-informes-plugin. Al ser un plugin como cualquier otro,
sino que tambin puede ser suprimida en el siguiente, ms prolija, camino, lo que
definitivamente desactiva el proyecto-INFO Reports.
1. <proyecto
2.
3.
4.
5.
...
6.
<Informes>
7.
<OutputDirectory> $ {} basedir / target / sitio </ OutputDirectory>
8.
<Plugins>
9.
<Plug-in>
10.
<artifactId> maven-project-info-informes-plugin </ artifactId>
11.
12.
<ReportSets>
13.
14.
15.
<ReportSet> </ reportSet>

</ ReportSets>
</ Plugin>
16.
</ Plugins>
17.
</ Informes>
18.
...
19. </ Project>
La otra diferencia es la OutputDirectory elemento del plug-in . En el caso de que se

informa, el directorio de salida es $ {} basedir / target / sitio de forma
predeterminada.
Conjuntos de informe
Es importante tener en cuenta que un plugin individuo puede tener mltiples
objetivos. Cada meta puede tener una configuracin independiente. Conjuntos de
informes configurar la ejecucin de los objetivos de un plugin informe. Le suena familiar
- deja-vu? Lo mismo se dijo acerca de la acumulacin de ejecucin elemento con una
diferencia: no puede enlazar un informe a otra fase. Lo siento.
Por ejemplo, suponga que desea configurar el javadoc: javadoc objetivo de vincular a
" http://java.sun.com/j2se/1.5.0/docs/api/ ", pero slo el javadoc objetivo (no el
objetivo maven- javadoc-plugin: tarro ). Tambin nos gustara que esta
configuracin hace pasar a sus hijos, y SET hered a la verdadera. El reportSet se
parecera a lo siguiente:
1. <proyecto
2.
3.
4.
5.
...
6.
<Informes>
7.
8.
<Plugins>
<Plug-in>
9.
...
10.
<ReportSets>
11.
<ReportSet>
12.
<id> sunlink </ id>
13.
<informes>
14.
<informe> javadoc </ informe>
15.
</ informes>
16.
17.
<Configuration>
18.
<enlaces>
19.
20.
21.
22.
23.
24.
<link> http://java.sun.com/j2se/1.5.0/docs/api/ </ link>

</ enlaces>
</ Configuration>
</ ReportSet>
</ ReportSets>
</ Plugin>
25.
</ Plugins>
26.
</ Informes>
27.
...
28. </ Project>
Entre construccin ejecuciones y presentacin de informes reportSets , debe quedar

claro ahora por qu es que existen. En el sentido ms simple, que profundizan en la
configuracin. El POM debe tener una forma no slo para configurar los plugins, pero
tambin debe configurar los objetivos individuales de los plugins.Ah es donde estos
elementos llegan, dando la granularidad ltima POM en control de su destino de
construccin.
Ms informacin sobre el proyecto

A pesar de que la informacin anterior es suficiente para conseguir un control firme
sobre la autora POM, hay muchos ms elementos para hacer la vida ms fcil del
desarrollador. Muchos de estos elementos estn relacionados con la generacin de sitio,
pero al igual que todas las declaraciones POM, que se puede utilizar para cualquier
cosa, dependiendo de cmo ciertos plugins utilizan. Los siguientes son los elementos
ms simples:
Nombre : Los proyectos tienden a tener nombres de conversacin, ms all de

la artifactId . Los ingenieros de Sun no se refirieron a su proyecto como "java-1.5",
sino que simplemente lo llamaron "Tigre". Aqu es donde para establecer dicho valor.
Descripcin : Descripcin de un proyecto siempre es buena. Aunque esto no debe
sustituir a la documentacin formal, un comentario rpido a cualquier lector del POM
es siempre til.
URL : La URL, como el nombre, no es necesario. Este es un buen gesto para los
usuarios de los proyectos, sin embargo, para que sepan dnde vive el proyecto.
inceptionYear : Este es otro buen punto de documentacin. Ser al menos ayudar a
recordar dnde ha pasado los ltimos aos de su vida.
licencias
1. <licencias>
2.
<Licencia>
3.
<nombre> Apache License, Version 2.0 </ name>
4.
<url> https://www.apache.org/licenses/LICENSE-2.0.txt </ url>
5.
<distribucin> repo </ distribucin>
6.
7.
<comentarios> Una licencia de negocios OSS </ comentarios>

</ Licencia>
8. </ licencias>
Las licencias son documentos legales que definen cmo y cundo se pueden usar un
proyecto (o partes de un proyecto). Tenga en cuenta que un proyecto debe mostrar slo
las licencias que pueden aplicarse directamente a este proyecto, y no detallan licencias
que se aplican a las dependencias de este proyecto. Maven actualmente hace poco con
estos documentos que no sean los muestra en los sitios generados. Sin embargo, se
habla de flexin para los diferentes tipos de licencias, obligando a los usuarios a aceptar
acuerdos de licencia para ciertos tipos de proyectos (fuente no abierta).
nombre , url y comentarios : son explica por s mismo, y se han encontrado antes en
otras capacidades. El cuarto elemento es la licencia:
Distribucin : Esta describe cmo el proyecto puede ser distribuido legalmente. Los
dos mtodos son declarados repo (que se pueden descargar de un repositorio de
Maven) o manual (que se deben instalar manualmente).
Organizacin
La mayora de los proyectos estn a cargo de algn tipo de organizacin (empresa,
grupo privado, etc.). Aqu es donde se establece la informacin ms bsica.
1. <proyecto
2.
3.
4.
5.
...
6.
<Organizacin>
7.
<nombre> Codehaus Mojo </ name>
8.
<url> http://mojo.codehaus.org </ url>
9.
</ Organizacin>
10. </ Project>
Desarrolladores
Todos los proyectos consisten en archivos que se crearon, en algn momento, por una
persona. Al igual que los otros sistemas que rodean a un proyecto, por lo que se pueden
hacer las personas involucradas en un proyecto de tener una participacin en el
proyecto. Los desarrolladores son presumiblemente miembros del ncleo de desarrollo
del proyecto. Tenga en cuenta que, a pesar de una organizacin puede tener muchos
desarrolladores (programadores) como miembros, no es buena forma para listar a todos
como desarrolladores, pero slo aquellos que son directamente responsables por el
cdigo. Una buena regla general es que si la persona no debe contactarse con el
proyecto, no ser necesario enumerar aqu.
1. <proyecto
2.
3.
4.
5.

...
6.
<desarrolladores>
7.
<Desarrollador>
8.
<id> jperez </ id>
9.
<nombre> John Doe </ name>
10.
<email> jdoe@example.com <correo electrnico>
11.
<url> http://www.example.com/jdoe </ url>
12.
<organizacin> ACME </ organizacin>
13.
<organizationUrl> http://www.example.com </ organizationUrl>
14.
<funciones>
15.
<funcin> arquitecto </ papel>
16.
<funcin> desarrollador </ papel>
17.
</ Papeles>
18.
<zona horaria> Amrica / New_York </ zona horaria>
19.
<propiedades>
20.
<picUrl> http://www.example.com/jdoe/pic </ picUrl>
21.
</ Properties>
22.
</ Desarrollador>
23.
</ Desarrolladores>
24.
...
25. </ Project>
Identificacin , nombre , correo electrnico : Estas corrospond a la identificacin del

desarrollador (probablemente algn identificador nico en toda la organizacin),
nombre y direccin de correo electrnico del desarrollador.
organizacin , organizationUrl : Como habr adivinado, se trata de nombre de la
organizacin de los desarrolladores y es URL, respectivamente.
papeles : Un papel deben especificar las acciones estndar que la persona que es
responsable. Al igual que una sola persona puede usar muchos sombreros, una sola
persona puede asumir mltiples papeles .
zona horaria : Una hora de la zona de identificacin vlida como Amrica /
New_York o Europe / Berlin , o un ajuste horario (y fraccin) numrica respecto a
UTC donde vive el desarrollador, por ejemplo, -5 o +1 . ID de zona horaria son muy
preferidos debido a que no se ven afectados por el horario de verano y los cambios de
zona horaria. Consulte la IANA para la base de datos de zona horaria oficial y una lista
en Wikipedia .
Propiedades : Este elemento es donde cualquier otra propiedad sobre la persona se
encuentre. Por ejemplo, un enlace a una imagen personal o un mango de mensajera
instantnea. Diferentes plugins pueden utilizar estas propiedades, o pueden ser
simplemente para otros desarrolladores que leyeron el POM.
colaboradores
Colaboradores son como los desarrolladores todava desempean un papel auxiliar en
el ciclo de vida de un proyecto. Tal vez el colaborador enva en una correccin de
errores, o se aade algo de documentacin importante. Un proyecto de cdigo abierto
sana es probable que tenga ms colaboradores que los desarrolladores.
1. <proyecto
2.
3.
4.
5.
...
6.
<colaboradores>
7.
<Colaborador>
8.
<nombre> Noelle </ name>
9.
<email> some.name@gmail.com </ email>
10.
<url> http://noellemarie.com </ url>
11.
<organizacin> Noelle Marie </ organizacin>
12.
<organizationUrl> http://noellemarie.com </ organizationUrl>
13.
<funciones>
14.
<funcin> probador </ papel>
15.
</ Papeles>
16.
<zona horaria> Amrica / Vancouver </ zona horaria>
17.
<propiedades>
18.
<gtalk> some.name@gmail.com </ gtalk>
19.
</ Properties>
20.
</ Colaborador>
21.
</ Colaboradores>
22.
...
23. </ Project>
Colaboradores contienen el mismo conjunto de elementos que los desarrolladores sans

la Identificacin del elemento.
Configuracin del entorno

Gestin de Problemas
Esto define el sistema de seguimiento de defectos ( Bugzilla , TestTrack , ClearQuest ,
etc) que se utiliza. Aunque no hay nada que un plugin del uso de esta informacin para
algo, su utiliza principalmente para la generacin de la documentacin del proyecto.
1. <proyecto
2.
3.
4.
5.
...
6.
<IssueManagement>
7.
<sistema> Bugzilla </ sistema>
8.
<url> http://127.0.0.1/bugzilla/ </ url>
9.
</ IssueManagement>
10.
...
11. </ Project>
Gestin de la Integracin Continua

Los sistemas de compilacin de integracin continua en base a los factores
desencadenantes o tiempos (como, por horas o por das) han crecido a favor sobre el
manual se basa en los ltimos aos. A medida que los sistemas de compilacin se han
vuelto ms estandarizada, por lo que los sistemas que ejecutan el gatillo de
formaciones. Aunque la mayora de la configuracin es hasta el programa especfico
utilizado (Continuum, Control de velocidad, etc.), hay algunas configuraciones que
pueden tener lugar dentro del POM. Maven ha capturado a algunos de los ajustes
recurrentes dentro del conjunto de elementos del notificador. Un notificador es la manera
en que las personas son notificados de ciertos estados de construccin. En el siguiente
ejemplo, el POM est estableciendo un notificador de tipoelectrnico (es decir, correo
electrnico), y la configuracin de la direccin de correo electrnico para usar en el
activas especficas sendOnError ,sendOnFailure , y
no sendOnSuccess o sendOnWarning .
1. <proyecto
2.
3.
4.
5.
...
6.
<CiManagement>
7.
<sistema> continuo </ sistema>
8.
<url> http://127.0.0.1:8080/continuum </ url>
9.
<Notificadores>
10.
<Notificador>
11.
<tipo> correo electrnico </ type>
12.
<sendOnError> verdadera </ sendOnError>
13.
<sendOnFailure> verdadera </ sendOnFailure>
14.
<sendOnSuccess> false </ sendOnSuccess>
15.
<sendOnWarning> false </ sendOnWarning>
16.
<configuration> <direccin> continuum@127.0.0.1 </ address> </ co

nfiguration>
17.
</ Notificador>
18.
</ Notificadores>
19.
</ CiManagement>
20.
...
21. </ Project>
Listas de correo
Las listas de correo son una gran herramienta para mantenerse en contacto con la gente
acerca de un proyecto. La mayora de las listas de correo son para los desarrolladores y
usuarios.
1. <proyecto
2.
3.
4.
5.
...
6.
<LISTASDECORREO>
7.
<Lista de correo>
8.
<nombre> Lista de usuarios </ name>
9.
<suscribirse> user-subscribe@127.0.0.1 </ suscripcin>
10.
<darse de baja> user-unsubscribe@127.0.0.1 </ darse de baja>
11.
<mensaje> user@127.0.0.1 </ mensaje>
12.
<archivo> http://127.0.0.1/user/ </ Archivo>
13.
<OtherArchives>
14.
<otherArchive> http://base.google.com/base/1/127.0.0.1 </ otherAr

chive>
15.
</ OtherArchives>
16.
</ Lista de correo>
17.
</ Listas de correo>
18.
...
19. </ Project>
suscribirse , darse de baja : Existen elementos especifican las direcciones de correo

electrnico que se utilizan para llevar a cabo las acciones relativas Para suscribirse a
la lista de usuarios anteriormente, un usuario podra enviar un correo electrnico a
user-subscribe@127.0.0.1.
Archivo : Este elemento especifica la direccin URL del archivo de correo antiguo de
listas de correo, si es que existe. Si hay archivos duplicados, que se pueden
especificar bajo otherArchives.
mensaje : La direccin de correo electrnico, que se podra utilizar con el fin de
publicar una entrada en la lista de correo. Tenga en cuenta que no todas las listas de
correo tienen la capacidad de publicar en (tales como una lista de fallos de
compilacin).
SMC
SCM (Software Configuration Management, tambin llamado Cdigo fuente / Gestin de
control o, de manera sucinta, el control de versiones) es una parte integral de cualquier
proyecto saludable. Si su proyecto Maven utiliza un sistema de SCM (lo hace, no lo
hace?), Entonces aqu es donde se coloca la informacin en el POM.
1. <proyecto
2.
3.
4.
5.
...
6.
<SMC>
7.
<conexin> SMC: SVN: http: //127.0.0.1/svn/my-project </ conexin>
8.
<DeveloperConnection> SMC: SVN: https: //127.0.0.1/svn/my-project </

DeveloperConnection>
9.
<tag> CABEZA </ tag>
10.
<url> http://127.0.0.1/websvn/my-project </ url>
11.
</ Scm>
12.
...
13. </ Project>
conexin , DeveloperConnection : Los dos elementos de conexin transmiten a

cmo uno es conectar al sistema de control de versiones a travs de Maven. En caso
de conexin requiere acceso de lectura para Maven para ser capaz de encontrar el
cdigo fuente (por ejemplo, una actualizacin), DeveloperConnection requiere una
conexin que le dar acceso de escritura. El proyecto Maven ha dado lugar a otro
proyecto llamado Maven SMC, lo que crea una API comn para cualquier MEC que
deseen implementarlo. Los ms populares son CVS y Subversion, sin embargo, existe
una creciente lista de otros apoyados MEC . Todas las conexiones se realizan a travs
de SCM una estructura de URL comn.
SMC: [proveedor]: [provider_specific]
Donde el proveedor es el tipo de sistema de SCM. Por ejemplo, la conexin a un

repositorio CVS puede tener este aspecto:
SMC: cvs: pserver: 127.0.0.1: / cvs / root: mi-proyecto
etiqueta : especifica la etiqueta que este proyecto vive bajo. (Que significa cabeza, la
raz SMC) debe ser el predeterminado.
url : Un repositorio navegable pblicamente. Por ejemplo, a travs de ViewCVS.
Requisitos previos
El POM puede tener ciertos requisitos previos para poder ejecutar correctamente. Por
ejemplo, tal vez hubo un arreglo en Maven 2.0.3 que necesita con el fin de implementar
el uso de SFTP. Aqu es donde se aplica los requisitos previos a la construccin. Si
stas no se cumplen, Maven fallar la acumulacin incluso antes de empezar. El nico
elemento que existe como un requisito previo en POM 4.0 es el elemento experto, que
tiene un nmero de versin mnima.
1. <proyecto
2.
3.
4.
5.
...
6.
<requisitos previos>
7.
<experto> 2.0.6 </ experto>
8.
</ Requisitos previos>
9.
...
10. </ Project>
repositorios
Los repositorios son colecciones de artefactos que se adhieren a la estructura de
directorios del repositorio Maven. Con el fin de ser un repositorio de artefactos Maven,
un archivo POM debe vivir dentro de la estructura $ BASE_REPO / groupId /
artifactId / versin / artifactId-version.pom . $ BASE_REPO puede ser local
(estructura de archivos) o (URL base) a distancia; la disposicin restante ser el
mismo. Existen repositorios como un lugar para recoger y almacenar artefactos.Cada
vez que un proyecto tiene una dependencia de un artefacto, Maven primero intentar
utilizar una copia local del artefacto especificado. Si ese artefacto no existe en el
repositorio local, que entonces intentar descargar de un repositorio remoto. Los
elementos del repositorio dentro de un POM especifican los repositorios alternativos
para la bsqueda.
El repositorio es una de las caractersticas ms potentes de la comunidad Maven. El
repositorio central de Maven predeterminado vive
enhttps://repo.maven.apache.org/maven2/ . Otra fuente de artefactos todava no est en
Ibiblio es la Codehaus instantneas repo.
1. <proyecto
2.
3.
4.
5.
...
6.
<repositorios>
7.
8.
<Repositorio>
<comunicados>
9.
10.
<updatePolicy> siempre </ updatePolicy>
11.
<checksumPolicy> advertir </ checksumPolicy>
12.
</ Prensa>
13.
<Instantneas>
14.
<enabled> verdadera </ enabled>
15.
<updatePolicy> no </ updatePolicy>
16.
<checksumPolicy> fallar </ checksumPolicy>
17.
</ Instantneas>
18.
<id> codehausSnapshots </ id>
19.
<nombre> Codehaus instantneas </ name>
20.
<url> http://snapshots.maven.codehaus.org/maven2 </ url>
21.
22.
</ Repositorio>
23.
</ Repositorios>
24.
<PluginRepositories>
25.
...
26.
</ PluginRepositories>
27.
...
28. </ Project>
comunicados , instantneas : Estas son las polticas para cada tipo de artefacto, de
lanzamiento o una instantnea. Con estos dos conjuntos, un POM tiene el poder de
alterar las polticas para cada tipo independiente de la otra dentro de un mismo
repositorio. Por ejemplo, uno puede decidir habilitar slo las descargas instantneas,
posiblemente para fines de desarrollo.
permitido : verdadero o falso a si este repositorio est habilitado para el tipo
respectivo ( liberaciones o instantneas ).
updatePolicy : Este elemento especifica la frecuencia con actualizaciones deben
intentar que se produzca. Maven comparar marca de tiempo del POM local
(almacenada en el archivo maven-metadatos de un repositorio) para el mando a
distancia. Las opciones son: siempre , todos los das (por defecto),intervalo:
X (donde X es un nmero entero en minutos) o no .
checksumPolicy : Cuando Maven despliega archivos al repositorio, tambin despliega
archivos de control correspondientes. Sus opciones son para ignorar ,fallar ,
o avisar sobre las sumas de comprobacin que faltan o incorrectos.
diseo : En la descripcin anterior de repositorios, se mencion que todos ellos siguen
un diseo comn. Esto es sobre todo correcto. La disposicin introducida con Maven 2
es la disposicin por defecto para los repositorios utilizados por Maven ambos 2 y
3; Sin embargo, Maven 1.x tena un diseo diferente. Utilice este elemento para
especificar qu si es por defecto o legado .
repositorios de complementos
Los repositorios son el hogar de dos grandes tipos de artefactos. El primero son
artefactos que se utilizan como dependencias de otros artefactos. Estos son la mayora
de los plugins que residen en el centro. El otro tipo de artefacto es plugins. Plugins de
Maven son en s mismos un tipo especial de artefacto. Debido a esto, repositorios de
complementos pueden ser separados de otros repositorios (aunque, todava tengo que
escuchar un argumento convincente para hacerlo). En cualquier caso, la estructura de
la pluginRepositories bloque elemento es similar al elemento de
repositorios. Los pluginRepository elementos cada uno especifican una ubicacin
remota del lugar donde Maven puede encontrar nuevos plugins.
Gestin de la distribucin
gestin de la distribucin acta exactamente como suena: gestiona la distribucin del

artefacto y archivos de soporte generados durante el proceso de construccin. A partir
de los ltimos elementos primero:
1. <proyecto
2.
3.
4.
5.
...
6.
<DistributionManagement>
7.
...
8.
<downloadURL> http://mojo.codehaus.org/my-project </ downloadURL>
9.
<status> desplegado </ status>
10.
</ DistributionManagement>
11.
...
12. </ Project>
downloadURL : es la URL del repositorio de donde otra POM puede sealar el fin de
apoderarse de este artefacto POM. En los trminos ms simples, nos dijeron que el
POM cmo subirlo (a travs del repositorio / url), pero desde donde puede la descarga
pblica que? Este elemento responde a esa pregunta.
estado : Atencin! Como un pjaro de beb en un nido, el estado no debe ser tocado
por la mano del hombre! La razn de esto es que Maven establecer el estado del
proyecto, cuando se transporta a cabo en el repositorio. Sus tipos vlidos son los
siguientes.
Ninguno : Sin condicin especial. Este es el valor predeterminado para un POM.
convertido : El gestor del repositorio convierte este POM de una versin anterior a
Maven 2.
Compaero : Esto podra fcilmente haber sido llamado sincronizada. Esto
significa que este artefacto se ha sincronizado con un repositorio pareja.
desplegado : Con mucho, el estado ms comn, lo que significa que este
artefacto se despliega desde una instancia de Maven 2 o 3. Esto es lo que se
obtiene cuando se implementa de forma manual utilizando la fase de despliegue
de lnea de comandos.
verificado : Este proyecto ha sido verificado, y se debe considerar finalizado.
Repositorio
En caso de que el elemento de repositorios especifica en el POM la ubicacin y la forma
en la que Maven puede descargar artefactos remotos para su uso por el proyecto actual,
distributionManagement especifica dnde (y cmo) este proyecto se llega a un
repositorio remoto cuando est desplegada. Los elementos de depsito se utilizan para
la distribucin instantnea si el snapshotRepository no est definido.
1. <proyecto
2.
3.
4.
5.
...
6.
7.
<Repositorio>
8.
<uniqueVersion> false </ uniqueVersion>
9.
<id> corp1 </ id>
10.
<nombre> diccionario de la empresa </ name>
11.
<url> scp: // repo / maven2 </ url>
12.
13.
</ Repositorio>
14.
<SnapshotRepository>
15.
<uniqueVersion> verdadera </ uniqueVersion>
16.
<id> propSnap </ id>
17.
<nombre> Propulsores de instantneas </ name>
18.
<url> SFTP: //propellers.net/maven </ url>
19.
<layout> legado </ layout>
20.
</ SnapshotRepository>
21.
...
22.
23.
...
24. </ Project>
Identificacin , Nombre : El ID se utiliza para identificar de forma exclusiva este

repositorio entre muchos, y el nombre es una forma legible por humanos.
uniqueVersion : La versin nica toma una verdadera o falsa valor para indicar si
los artefactos desplegados en este repositorio debe obtener un nmero de versin
generada de forma nica, o utilizar el nmero de versin definido como parte de la
direccin.
url : Este es el ncleo del elemento repositorio. En l se especifica tanto la ubicacin
como el protocolo de transporte que se utiliza para transferir un artefacto construido (y
el archivo POM, y los datos de suma de comprobacin) en el repositorio.
Disposicin : Estos son los mismos tipos y finalidad que el elemento de diseo
definido en el elemento de repositorio. Son predeterminado y legado .
Distribucin del sitio

Ms de distribucin a los repositorios, distributionManagement es responsable de
definir cmo implementar sitio y la documentacin del proyecto.
1. <proyecto
2.
3.
4.
5.
...
6.
7.
...
8.
<Sitio>
9.
<id> mojo.website </ id>
10.
<nombre> Mojo sitio web </ name>
11.
<url> scp: //beaver.codehaus.org/home/projects/mojo/public_html/ </

url>
12.
</ Site>
13.
...
14.
15.
...
16. </ Project>
Identificacin , nombre , url : Estos elementos son similares a sus contrapartes ms

arriba en la distributionManagement repositorio elemento.
reubicacin
1. <proyecto
2.
3.
4.
5.
...
6.
7.
...
8.
<Reubicacin>
9.
<groupId> org.apache </ groupId>
10.
11.
12.
<mensaje> Hemos movido el Proyecto bajo Apache </ message>
13.
14.
</ Reubicacin>
...
15.
16.
...
17. </ Project>
Los proyectos no son estticas; que son seres vivos (o muriendo cosas, como sea el
caso). Una cosa comn que sucede a medida que crecen los proyectos, es que se ven
obligados a pasar a cuartos ms adecuados. Por ejemplo, cuando el proyecto de cdigo
abierto un gran xito junto mueve bajo el paraguas de Apache, que sera bueno para dar
a sus usuarios como el heads-up que el proyecto est siendo renombrado
a org.apache: mi-proyecto: 1.0 . Adems de especificar la nueva direccin, tambin
es una buena forma para proporcionar un mensaje que explica por qu.
perfiles
Una nueva caracterstica del POM 4.0 es la capacidad de un proyecto para cambiar los
ajustes en funcin del entorno en el que se est construyendo. Un perfilelemento
contiene tanto una activacin opcional (un disparador perfil) y el conjunto de cambios
que deban introducirse en el POM si ese perfil ha sido activado. Por ejemplo, un
proyecto construido para un entorno de prueba puede apuntar a una base de datos
diferente a la de la implantacin final. O dependencias pueden ser extradas de
diferentes repositorios basados en la versin del JDK utilizada. Los elementos de
perfiles son las siguientes:
1. <proyecto
2.
3.
4.
5.
...
6.
<Perfiles>
7.
<Perfil>
8.
<id> prueba </ id>
9.
<activacin> ... </ activacin>
10.
11.
<mdulos> ... </ mdulos>
12.
<repositorios> ... </ repositorios>
13.
<pluginRepositories> ... </ pluginRepositories>
14.
15.
<informes> ... </ informes>
16.
<DependencyManagement> ... </ DependencyManagement>
17.
<distributionManagement> ... </ distributionManagement>
18.
19.
</ Profile>
</ Perfiles>
20. </ Project>
Activacin
Activaciones son la clave de un perfil. La potencia de un perfil proviene de su capacidad
de modificar el POM bsico slo bajo ciertas circunstancias. Estas circunstancias se
especifican a travs de una activacin del elemento.
1. <proyecto
2.
3.
4.
5.
...
6.
<Perfiles>
7.
<Perfil>
8.
<id> prueba </ id>
9.
<Activacin>
10.
<activeByDefault> false </ activeByDefault>
11.
<JDK> 1.5 </ jdk>
12.
<Os>
13.
<nombre> Windows XP </ nombre>
14.
<familia> de Windows </ familia>
15.
<arch> 86 </ arch>
16.
17.
</ Os>
18.
<Propiedad>
19.
<nombre> de tipo gorrin </ name>
20.
<valor> africano </ value>
21.
</ Property>
22.
<Archivo>
23.
<existe> $ {} basedir /file2.properties </ existe>
24.
25.
<faltante> $ {} basedir /file1.properties </ faltante>

</ File>
26.
</ Activacin>
27.
...
28.
29.
</ Profile>
</ Perfiles>
30. </ Project>
La activacin se produce cuando uno o ms de los criterios especificados se han

cumplido. Cuando se encuentra el primer resultado positivo, el proceso se detiene y el
perfil se marca como activo.
JDK : la activacin se ha construido en, cheque centrado en Java en

el JDK elemento. Esto activar si la prueba se ejecuta con un nmero de versin JDK
que coincida con el prefijo dado. En el ejemplo anterior, 1.5.0_06 coincidirn. Gamas
tambin se admiten como de Maven 2.1. Ver el experto-ejecutor-plugin para ms
detalles acerca de los rangos compatibles.
OS : El sistema operativo elemento puede definir algunas propiedades especficas
del sistema operativo que se muestran arriba. Ver el maven-ejecutor-pluginsRegla
RequireOS para ms detalles acerca de los valores del sistema operativo.
Propiedad : El perfil se activar si Maven detecta una propiedad (un valor que
puede dejar de hacer referencia dentro del POM por $ {nombre} ) del
correspondiente nombre = valor par.
archivo : Por ltimo, un nombre de archivo dado puede activar el perfil por
la existencia de un archivo, o si est ausente . NOTA : interpolacin para este
elemento est limitado a $ {} basedir , las propiedades del sistema y propiedades
de la solicitud.
La activacin elemento no es la nica manera de que un perfil puede ser

activado. El settings.xml de archivo activeProfile elemento puede contener del
perfil de id . Tambin se pueden activar de forma explcita a travs de la lnea de
comandos a travs de una lista separada por comas despus de la -P indicador (por
ejemplo, -P cobertura de cdigo ).
Para ver qu perfil se activar en una cierta acumulacin, utilice el experto-ayudaplugin .
mvn ayuda: activos perfiles
El BaseBuild Conjunto de Elementos (revisited)

Como se mencion anteriormente, la razn de los dos tipos de elementos de
construccin reside en el hecho de que no tiene sentido para un perfil para configurar
directorios de construccin o extensiones como lo hace en el nivel superior del
POM. Reguardless de en qu entorno se genera el proyecto, algunos valores se
mantienen constantes, tales como la estructura de directorios del cdigo fuente. Si
encuentra que su proyecto la necesidad de mantener dos conjuntos de cdigo para
diferentes entornos, puede ser prudente investigar refactorizacin la proyectar en dos o
ms proyectos separados.
Final
El POM Maven es grande. Sin embargo, su tamao es tambin una prueba de su
versatilidad. La capacidad de abstraer todos los aspectos de un proyecto en un solo
artefacto es de gran alcance, por decir lo menos. Atrs han quedado los das de de
scripts de construccin dispares y dispersos documentacin relativa a cada proyecto
individual docenas. Junto con otras estrellas de Maven que componen la galaxia Maven
- una acumulacin del ciclo de vida bien definido, fcil de escribir y mantener plugins,
repositorios centralizados, configuraciones de todo el sistema y basadas en el usuario,
as como el creciente nmero de herramientas para hacer los trabajos de los
desarrolladores ms fcil de mantener proyectos complejos - el POM es la grande, pero
brillante, centro.
Los aspectos de esta gua se publicaron originalmente en el Maven 2 Pom Desmitificar .

Referencia POM

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Referencia POM

Cargado por

Copyright:

Formatos disponibles

Referencia POM

El POM XSD 4.0.0 y referencia del descriptor de la documentacin

xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance"

xsi: schemaLocation = "http://maven.apache.org/POM/4.0.0

http://maven.apache.org/xsd/maven-4.0.0.xsd " >

<! - -> Los fundamentos

<groupId> ... </ groupId>

<artifactId> ... </ artifactId>

<versin> ... </ version>

<empaque> ... </ empaque>

<dependencias> ... </ dependencias>

<parent> ... </ parent>

<DependencyManagement> ... </ DependencyManagement>

<mdulos> ... </ mdulos>

<propiedades> ... </ properties>

<! - -> Configuracin de generacin

<crear> ... </ construccin>

<informes> ... </ informes>

<! - Ms informacin sobre el proyecto ->

<nombre> ... </ name>

<description> ... </ description>

<url> ... </ url>

<inceptionYear> ... </ inceptionYear>

<licencias> ... </ licencias>

<organizacin> ... </ organizacin>

<desarrolladores> ... </ desarrolladores>

<colaboradores> ... </ colaboradores>

<! - Configuracin del entorno ->

<issueManagement> ... </ issueManagement>

<ciManagement> ... </ ciManagement>

<LISTASDECORREO> ... </ Listas de correo>

<SMC> ... </ scm>

<requisitos previos> ... </ requisitos previos>

<repositorios> ... </ repositorios>

<pluginRepositories> ... </ pluginRepositories>

<distributionManagement> ... </ distributionManagement>

<perfiles> ... </ perfiles>

42. </ Project>

xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance"

xsi: schemaLocation = "http://maven.apache.org/POM/4.0.0

http://maven.apache.org/xsd/maven-4.0.0.xsd " >

<groupId> org.codehaus.mojo </ groupId>

<artifactId> mi-proyecto </ artifactId>

<versin> 1.0 </ version>

10. </ Project>

groupId : Esto generalmente es nico entre una organizacin o un proyecto. Por

Los tres elementos mencionados anteriormente apuntan a una versin especfica de

envasado : Ahora que tenemos nuestra estructura de direccin del groupId:

xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance"

xsi: schemaLocation = "http://maven.apache.org/POM/4.0.0

http://maven.apache.org/xsd/maven-4.0.0.xsd " >

<empaque> guerra </ empaque>

Cuando se declara ningn embalaje, Maven asume el artefacto es el valor por

clasificador : De vez en cuando puede encontrar un quinto elemento en la

similares.Maven resuelve ambos problemas a travs de un repositorio local comn de

xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance"

xsi: schemaLocation = "http://maven.apache.org/POM/4.0.0

https://maven.apache.org/xsd/maven-4.0.0.xsd " >

<groupId> JUnit </ groupId>

<artifactId> JUnit </ artifactId>

<versin> 4.0 </ version>

<tipo> tarro </ type>

<scope> prueba </ scope>

<opcional> verdadera </ opcional>