¿perfiles maven o perfiles de resorte?

Question

muchas aplicaciones de Java están compiladas con maven. maven tiene el concepto de Perfiles, es realmente útil crear un paquete de lanzamiento para diferentes entornos. p.ej. dev/test/prod utilizando diferentes path/jndiname/security rule/properties files ... Creo que no tengo que enumerar los códigos aquí para explicarlo.

Spring es un marco muy agradable y popular para el desarrollo de Java, ya que spring3 también ha admitido el concepto de perfiles.

Ahora viene la pregunta, para lanzar a diferentes propósitos de ENV, ¿cuál es mejor? ahora prefiero el perfil de maven. desde la primavera tiene que copiar cada definición de frijol en cada perfil. y necesita un inicializador/propiedad para que la primavera sepa qué perfil debe activarse.

pero creo que el perfil de resorte es más flexible que el perfil de maven.

¿qué opinas? Por favor, da algunos consejos. gracias.

Answer 1

Los perfiles Maven proporcionarían una solución de tiempo de compilación, mientras que los perfiles SpringFramework proporcionarían una alternativa de tiempo de ejecución. Creo que esta es la primera pregunta que uno se puede hacer a sí mismo: si quiere tener un solo paquete que se pueda implementar en diferentes entornos, o si quiere que la herramienta de compilación proporcione diferentes paquetes de acuerdo con el entorno de destino.

Una cosa a tener en cuenta es que pueden surgir muchas preguntas si tiene paquetes diferentes implementados en servidores diferentes. En mi lugar de trabajo, por ejemplo, si estoy implementando un paquete para corregir una falla que ocurría previamente en el entorno de producción, una política de la compañía establecería que el único escenario aceptable es que tengo el mismo paquete de solución en QA y en servidores de producción.

Answer 2

Si necesita artefactos diferentes, entonces vaya con maven. Si solo se trata de una configuración real que se puede configurar DESPUÉS de que se construya el artefacto, entonces los perfiles de usuario de Spring.

Answer 3

Creo que depende de sus requisitos. Si tiene dependencias diferentes basadas en el entorno (es decir, controladores jdbc, etc.), querrá usar maven para resolver esto.

Si solo se trata de configurar su implementación, probablemente sea mejor utilizar la primavera.

Answer 4

Como se mencionó en el otro responde: todo depende de cómo se trabaja :)

Lo que ocurrió en los últimos años el uso de Maven y ahora el muelle 3.1 perfiles es la siguiente:

• utilizamos el maven-release-plugin para cortar lanzamientos. esto causa problemas con los entornos si usáramos perfiles de maven ya que necesitaríamos reconstruir la versión o al menos la etiqueta con cada perfil de maven
• , por lo que creamos archivos .war para todos los entornos y usamos el resorte PropertyPlaceholderConfigurer para configurar la aplicación (o algún recurso JNDI dependiendo del cliente). Esto permite tener solo una ejecución de lanzamiento maven.
• los perfiles de resorte entran cuando los ambientes también difieren. por ejemplo, un servicio de autenticación que no está disponible en todos los entornos. Aquí ponemos ese servicio y lo ponemos en un perfil de primavera. Actuamos los perfiles de primavera en las propiedades que se lee en el PropertyPlaceholderConfigurer que usamos de todos modos.

hay algunos tutoriales agradables alrededor de cómo hacerlo:

• http://pio-tech.blogspot.ch/2012/01/using-spring-31-bean-definition.html
• http://steveschols.wordpress.com/2012/06/01/spring-3-1-unified-property-management-before-and-after/

que por lo general sólo utilizamos perfiles de Maven para dividir la acumulación en diferentes partes de la desarrolladores y la construcción de integración continua. En realidad, ya no los usamos para entornos de destino para los archivos .war. Todavía utilizamos perfiles maven para implementaciones automatizadas de bases de datos, que difieren más en comparación con las aplicaciones web (cantidad de datos, datos de prueba, ...), pero estas no se envían como un archivo zip más o menos.

Sin duda hay otras maneras de hacerlo. No creo que sea el final de la historia :)

Pero puede ayudar.

Answer 5

Me pasó a utilizar properties-maven-plugin para establecer una propiedad del sistema dependiendo de qué perfil de administrador se activó. Luego, en Spring, estaba activando programáticamente los perfiles que quería, dependiendo de la propiedad del sistema:

String activeProfile = System.getProperty ("myapp.profile");

appContext.getEnvironment(). SetActiveProfiles (....)

Por otra parte, cuando quería enlazar directamente los dos tipos de perfil (experta/primavera), que estaba estableciendo la propiedad spring.profiles.active a través del plugin maven.

Es posible que estas prácticas sean erróneas en el diseño, pero solucionaron mis problemas.