Specifica del percorso Java per il file delle proprietà

Question

Ho un progetto Java Spring, configurato con Maven. Poiché la quantità di unit test e i loro file di configurazione si sommano rapidamente, sto cercando di centralizzare le configurazioni di test su un file di proprietà (lo stesso, che viene utilizzato nella costruzione del progetto).

L'unità di test si trovano (rispetto al percorso del progetto, naturalmente) in albero

src/test/java/com (...)

I file di risorse per questi test sono in

src/test/resources(...)

E, infine, il file delle proprietà, che il file di risorse dovrebbero leggere, è nella directory

src/main/filters

Ora, ho una classe Junit dove specificare la posizione del file di configurazione in questo modo:

@ContextConfiguration(locations = { "classpath:com/initrode/quartz/SyncManagerJobTest-context.xml"}) 

Nel file di configurazione SyncManagerJobTest-context.xml c'è una linea

<context:property-placeholder location="/src/main/filters/deploy.local.properties"/> 

Questo si traduce in file delle proprietà da leggere dalla directory. Quello che mi piacerebbe leggere è il file delle proprietà, che si trova sotto src/main/filters. Ho provato a usare ../../ per attraversare la directory verso l'alto, ma questo non ha aiutato. Utilizzando classpath: non ha funzionato neanche. Potrei usare un percorso assoluto con "file:", ma ciò richiederebbe a tutti gli sviluppatori del progetto di modificare la configurazione, il che non è neanche positivo.

Per riassumere, la domanda è: come posso forzare il file di configurazione in src/test/resources/per leggere il file delle proprietà in src/main/filters?

E una domanda bonus correlata: quando si gestiscono i file in ambiente Java, ci sono altri modificatori di "file:" e "classpath:"?

Answer 1

Se si specifica src/main/filters come percorso risorse, Maven trasferirà le risorse su target/classes e anche le classi nella stessa posizione durante la compilazione. Quindi non hai un percorso relativo da gestire in quanto hanno la stessa radice. Se non fai qualcosa di simile, la directory dei filtri non sarà inclusa nella build.

Aggiornamento: Ovviamente il codice di test viene emesso nelle classi target/test, quindi per semplificare il test, è possibile specificare che src/main/filters venga copiato su target/test-classes durante la fase di processo-test-risorse. Ho modificato l'esempio per mostrare questo comportamento.

Se non lo si è già fatto, è possibile utilizzare build-helper-maven-plugin per aggiungere la cartella dei filtri come percorso della risorsa.

La configurazione di farlo si presenta così:

<plugin> 
    <groupId>org.codehaus.mojo</groupId> 
    <artifactId>build-helper-maven-plugin</artifactId> 
    <version>1.3</version> 
    <executions> 
    <execution> 
     <id>add-resource</id> 
     <phase>process-test-sources</phase> 
     <goals> 
     <goal>add-test-resource</goal> 
     </goals> 
     <configuration> 
     <resources> 
      <resource> 
      <directory>scr/main/filters</directory> 
      </resource> 
     </resources> 
     </configuration> 
    </execution> 
    </executions> 
</plugin> 

Answer 2

Per me, suona un po 'strano per mettere un file di proprietà in src/main/filters se non si prevede di utilizzare questo file come ... un filtro. Se questo file viene utilizzato come risorsa di test standard, perché non lo si inserisce in src/test/resources? Se vuoi filtrare alcuni file di risorse, perché non lo fai e usi le risorse filtrate? Mi sarei aspettato di vedere qualcosa di simile:

<build> 
    <!-- Filter resources --> 
    <filters> 
    <filter>src/main/filters/my-filter.properties</filter> 
    </filters> 
    <!-- Resources for src/main --> 
    <resources> 
    <resource> 
     <directory>src/main/resources</directory> 
     <filtering>true</filtering> 
    </resource> 
    </resources> 
    <!-- Resources for src/test --> 
    <testResources> 
    <testResource> 
     <directory>src/test/resources</directory> 
     <filtering>true</filtering> 
    </testResource> 
    </testResources> 
</build> 

mi può mancare qualcosa, ma penso che si stia mescolando alcuni concetti.Nel tuo caso (e se ho capito bene cosa stai cercando di fare), userei i profili e i filtri Maven per gestire la distribuzione di più ambienti. Date un'occhiata a:

• Maven profiles for multiple environments deployment
• A Maven2 multi-environment filter setup