Pregunta Donde en el camino del proyecto maven debería poner archivos de configuración que no son considerados recursos


Tengo un proyecto simple de Java Maven. Una de mis clases al ejecutar necesita cargar un archivo de configuración xml desde classpath. No quiero empaquetar dicho archivo xml al producir el jar, pero quiero incluir un archivo xml predeterminado en un ensamblado zip bajo una subcarpeta conf y también quiero que este xml predeterminado esté disponible en las pruebas unitarias para probarlo.

Como lo veo, hay 2 lugares posibles de este xml predeterminado:

  1. src/main/resources/conf/default.xml
  2. src/main/conf/default.xml

Ambas soluciones requieren acciones especiales pom:

  • En la solución 1, obtengo la copia automática en la carpeta de destino durante la construcción, lo que significa que está disponible para la prueba, pero también la obtengo en el contenedor que no quiero.

  • En la solución 2, obtengo el jar como lo quiero (sin el xml) pero tengo que copiar manualmente el xml a la carpeta de destino para estar disponible para la prueba. (No quiero agregar las subcarpetas de src en el classpath de prueba. Creo que es una mala práctica).

Pregunta: ¿cuál es la mejor solución de los dos?
- Si el correcto es 2, ¿cuál es la mejor manera de copiarlo en la carpeta de destino?
- ¿Hay alguna otra solución mejor y más común que esos dos?

(También leo ¿Dónde debería colocar los archivos de configuración de la aplicación para un proyecto Maven? pero me gustaría saber cuál es la "solución más correcta" desde el punto de vista de la "convención sobre la configuración" y este enlace proporciona algunas soluciones de tipo de configuración, pero no orientadas a convenciones. Quizás no haya uno, pero pregunto de todos modos. Además, las soluciones proporcionadas incluyen el plugin AntRun y ​​el plugin appAssembler y me pregunto si podría hacerlo sin ellos.


32
2018-06-08 22:16


origen


Respuestas:


La pregunta es, ¿cuál es la mejor solución de los dos? Si el correcto es 2, ¿cuál es la mejor manera de copiarlo a la carpeta de destino? ¿Hay alguna otra solución mejor y más común que esos dos?

Dado que desea que ese archivo se copie al target/classes carpeta, de alguna manera tiene que ser considerado como un recurso (por lo tanto, ya sea en virtud de src/main/resources o declarar src/main/conf como directorio de recursos). Y si no lo quiere en el jar final, configure el Plugin de Maven JAR para excluirlo:

<project>
  ...
  <build>
    <plugins>
      ...
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <version>2.3.1</version>
        <configuration>
          <excludes>
            <exclude>**/conf/*</exclude>
          </excludes>
        </configuration>
      </plugin>
      ...
    </plugins>
  </build>
  ...
</project>

Para la parte de ensamblaje, los descriptores de ensamblaje son bastante flexibles, por lo que debería ser posible lograr lo que desee independientemente de la elección. Sugeriría usar la configuración más fácil sin embargo.


39
2018-06-09 09:47



Puede colocarlo en src / test / conf / default.xml. Sus clases de prueba pueden encontrarlo, pero no se empacarán utilizando el método estándar.

Con un ensamblaje adicional, puede empaquetarlo desde allí. Ese paso siempre es necesario.

Una solución diferente podría ser crear un módulo maven separado y colocarlo en / src / main / resources / conf / .... Luego, haga de este jar una dependencia de prueba. No es necesario que realice ninguna configuración de complemento especial, pero creo que es excesivo para un solo archivo.


1
2018-06-08 22:26



Mi solución fue usar dos perfiles: desarrollo (predeterminado) y empaquetado

Mi sección / predeterminado contiene src / main / resources y src / main / conf. Yo llamo a esto mi perfil de Desarrollo, que es un perfil implícito.

Mi perfil de empaque es un perfil explícito que se define en la sección. Abajo / solo mencioné src / main / resources. Cuando estoy ejecutando mi script de empaquetado (actualmente tenemos esto externo a maven ya que está construyendo un RPM fuera de nuestra WAR), estoy ejecutando 'mvn install -Drpm' para activar mi perfil de Empaquetado (rpm es la identificación para el Empaquetado) perfil.

Si esto no fue lo suficientemente claro, no dude en hacer más preguntas.


1
2018-06-11 23:05