Maven

Maven 2.1.0+ soporta la encriptación de contraseñas de servidor.  Los principales casos de uso que abarca esta solución son:

  • múltiples usuarios comparten el mismo equipo (servidor, equipo de IC)
  • algunos usuarios tienen privilegios para desplegar artefactos Maven en repositoros y otros no.  Esto se aplicat también a operaciones de servidor, que requieran autorización, no solo a despliegues.
  • settings.xml se comparte entre usuarios.

La solución implementada añade las siguientes capacidades:

  • lo usuarios autorizados tienen un fichero settings-security.xml adicional en su carpeta ~/.m2
  • el fichero contiene o bien una contraseña maestra, usada para encriptar otras contraseñas o bien contiene una referencia a la ubicación de otro fichero, posiblemente en un sistema de almacenamiento extraible, que contendrá la contraseña maestra.  Esta contraseña se crea antes usando CLI
  • las entradas server de settings.xml contienen contraseñas y/o passhrases de almacenes de claves encriptadas – esto se realiza usando CLI después de haber creado la contraseña maestra y de haberla almacenado en la ubicación apropiada

Lee el resto de esta entrada »

Anuncios

Maven

Si tienes un proyecto maven multi-módulo y quieres construir solamente uno de los submódulos, puedes utilizar las opciones avanzadas del reactor, más concretamente:

  • -pl, –projects
    Construye solamente los proyectos del reactor especificados en vez de construir todos
  • -am, –also-make
    Si se especifica una lista de proyectos, también se construyen los proyectos requeridos por la lista

Así, si nos situamos en el el directorio P del proyecto padre y ejecutamos:

mvn install -pl B -am

esto construirá B y los módulos requeridos por B.

via

MAVEN Lifecycle

10/06/2016

Maven

Fundamentos básicos del ciclo de vida de la construcción

Maven se fundamenta en el concepto central de ciclo de vida de construcción (build lifecycle). Esto significa que el proceso de construcción y distribución de un artifact (artefacto = proyecto) concreto está definido claramente.

Para la persona que quiera construir un proyecto significa que solamente es necesario aprender un pequeño conjunto de comandos para construir cualquier proyecto Maven, y el POM se asegurará de que obtenga los resultados deseados.

Existen tres ciclos de vida en el sistema: default, clean y site. El ciclo de vida default controla el despliegue de tu proyecto, el ciclo de vida clean controla la limpieza de tu proyecto, mientras que el ciclo de vida site controla la creación del site de documentación de tu proyecto.

Lee el resto de esta entrada »

Maven

Para conseguir nuestro objetivo debemos seguir una serie de pasos:

  • Obtener el código fuente tal cual está
  • Asociarle una versión (probablemente eliminado el subfijo -SNAPSHOT) de modo que pueda ser identificado unívocamente
  • Construir, probar y empaquetar
  • Desplegar en un repositorio de artefactos donde pueda ser recuperado para su instalación
  • Etiquetar este estado en el SCM para que pueda ser asociado con el artefacto correspondiente
  • Asociar una nueva versión de desarrollo (probablemente subiendo el número de versión y añadiendo el subfijo -SNAPSHOT)
  • Construir y probar
  • Subir el cambio de versión de desarrollo al SCM

Bastante sencillo, no?

Lee el resto de esta entrada »

Maven

Para conseguir nuestro objetivo debemos seguir una serie de pasos:

  • Obtener el código fuente tal cual está
  • Asociarle una versión (probablemente eliminado el subfijo -SNAPSHOT) de modo que pueda ser identificado unívocamente
  • Construir y probar
  • Etiquetar este estado en el SCM para que pueda ser asociado con el artefacto correspondiente
  • Asociar una nueva versión de desarrollo (probablemente subiendo el número de versión y añadiendo el subfijo -SNAPSHOT)
  • Subir el cambio de versión de desarrollo al SCM
  • Obtener el código fuente de la versión etiquetada
  • Construir, probar y empaquetar
  • Desplegar en un repositorio de artefactos donde pueda ser recuperado para su instalación

Bastante sencillo, no?

Lee el resto de esta entrada »

Maven

Si alguna vez has trabajado con Maven sabrás que te permite definir propiedades personalizadas que se pueden utilizar como placeholders (marcadores o comodines) para reutilizar valores o con fines de configuración o incluso como un modo de configurar los recursos de tu construcción final usando filtros (filters).  Esto nos viene muy bien para definir configuraciones específicas por entorno.

Estas propiedades personalizadas se pueden definir en múltiples lugares.  Pero ¿qué ocurre cuando defines (o re-defines) la misma propiedad en múltiples lugares?  ¿Que definición tendrá precedencia sobre las otras?

El orden de precedencia a la hora de resolver el valor de las propiedades personalizadas en Maven es el siguiente:

  • Propiedades del sistema (system):  establecidas con -Dxyz=valor desde la línea de comandos
  • De/los perfil/es (profile) activo/s actualmente:  settings.xml del directorio de usuario primero, profiles.xml del directorio raiz del proyecto después, y los perfiles definidos en el pom.xml en último lugar.  Si están activos varios perfiles y una propiedad está definida en más de uno, el orden de precedencia se basa en el último perfil en que la propiedad ha sido definido, en orden alfabético del nombre del perfil.
  • En la sección properties del pom.xml
  • Por último, en los properties de los filtros.  Si una propiedad se define en múltiples filtros, el último (en orden de aparición en la sección filters) tiene precedencia sobre los otros.

vía

Tomcat
Para habilitar las trazas de logging tal y como se utilizan en la instalación por defecto de Tomcat 7, pero dentro del Eclipse usando WTP, debemos seguir los siguientes pasos:

  1. En la vista Project Explorer (o Navigator o Package Explorer) vamos a Servers –> Tomcat v7.0 Server at localhost-config –> Botón derecho –> Import –> General –> File System –> Next –> Navegamos a la carpeta $CATALINA_BASE/conf/ (donde $CATALINA_BASE es la carpeta de instalación del Tomcat 7) –> Seleccionamos el fichero logging.properties –> Finish
  2. Vamos a Run –> Run Configurations… –> Apache Tomcat –> Tomcat v7.0 Server at localhost –> Arguments –> Y en “VM arguments” añadimos:

    -Djava.util.logging.config.file="${workspace_loc}/Servers/Tomcat v7.0 Server at localhost-config/logging.properties" -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

    –> Apply

NOTA: Es posible que el nombre de la carpeta de configuración del servidor (Tomcat v7.0 Server at localhost-config) sea diferente o que el nombre de la configuración del lanzador (Tomcat v7.0 Server at localhost) sea distinta. Será necesario ajustarla acorde a tu configuración particular.

A %d blogueros les gusta esto: