Usando las propiedades de Maven settings.xml dentro del contexto Spring

Tengo un Mavensettings.xml archivo en mi~/.m2 directorio; se parece a esto:

<settings>
    <profiles>
        <profile>
            <id>mike</id>
            <properties>
                <db.driver>org.postgresql.Driver</db.driver>
                <db.type>postgresql</db.type>
                <db.host>localhost</db.host>
                <db.port>5432</db.port>
                <db.url>jdbc:${db.type}://${db.host}:${db.port}/dbname</db.url>
            </properties>
        </profile>
    </profiles>
    <activeProfiles>
        <activeProfile>mike</activeProfile>
    </activeProfiles>
    <servers>
        <server>
            <id>server_id</id>
            <username>mike</username>
            <password>{some_encrypted_password}</password>
        </server>
    </servers>
</settings>

Me gustaría usar estas propiedades dos veces

Una vez dentro de Mavenintegration-test fase para configurar y derribar mi base de datos. Usando el filtrado de Maven, esto está funcionando perfectamente.Una segunda vez cuando ejecuto mi aplicación Spring, lo que significa que necesito sustituir estas propiedades en miservlet-context.xml archivo durante Mavenresources:resources fase. Para propiedades en la sección superior desettings.xml, como${db.url}, esto funciona bien.No puedo encontrar la forma de sustituir el nombre de usuario de mi base de datos y la contraseña (descifrada) en Springservlet-context.xml expediente.

La parte pertinente de miservlet-context.xml archivo se ve como:

<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
    <property name="driverClassName"><value>${db.driver}</value></property>
    <property name="url"><value>${db.url}</value></property>
    <property name="username"><value>${username}</value></property>
    <property name="password"><value>${password}</value></property>
</bean>

El objetivo final aquí es que cada desarrollador tenga su propia configuración de Maven (y la base de datos en su propia máquina para las pruebas de integración) ... Y una configuración similar en el servidor Jenkins. No queremos compartir un nombre de usuario / contraseña / etc común.

Respuestas a la pregunta(3)

Su respuesta a la pregunta