Określanie ścieżki Java dla pliku właściwości

Question

Mam projekt Java Spring, skonfigurowany z Maven. Ponieważ liczba testów jednostkowych i ich pliki konfiguracyjne szybko się sumują, staram się scentralizować konfiguracje testowe do jednego pliku właściwości (tego samego, który jest używany przy budowaniu projektu).

Jednostka Testy znajdują się (w stosunku do ścieżki projektu, oczywiście) w drzewie

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

Pliki zasobów dla tych badań są w

src/test/resources(...)

i wreszcie, plik właściwości, co plik zasobów należy czytać, jest w katalogu

src/main/filters

teraz mam klasy Junit gdzie mogę określić lokalizację pliku konfiguracyjnego tak:

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

w pliku konfiguracyjnym SyncManagerJobTest-context.xml istnieje linia

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

Skutkuje to we właściwościach pliku, który ma być odczytany z katalogu. Chciałbym przeczytać plik właściwości, który znajduje się pod src/main/filters. Próbowałem używać ../../ do przechodzenia do katalogu w górę, ale to nie pomogło. Używanie ścieżki klasy: też się nie udało. Mógłbym użyć bezwzględnej ścieżki z "file:", ale to wymagałoby od każdego programisty w projekcie modyfikacji konfiguracji, co również nie jest dobre.

Podsumowując, pytanie brzmi: jak mogę wymusić plik konfiguracyjny w src/test/resources /, aby odczytać plik właściwości w src/main/filters?

I powiązane pytanie dodatkowe: czy podczas obsługi plików w środowisku Java istnieją inne modyfikatory niż "file:" i "classpath:"?

Answer 1

Jeśli określisz src/main/filters jako lokalizację zasobów, Maven przeniesie zasoby do target/classes, a także skompiluje klasy do tej samej lokalizacji podczas kompilacji. Wtedy nie masz względnej ścieżki, z którą możesz sobie poradzić, ponieważ mają one ten sam root. Jeśli nie zrobisz czegoś takiego, twój katalog filtrów nie zostanie dołączony do kompilacji.

Aktualizacja: Oczywiście kod testowy jest wysyłany do klas docelowych/testowych, więc aby uprościć testowanie, można określić, że src/main/filters jest kopiowane do podczas fazy testowania zasobów. Zmodyfiowałem ten przykład, aby pokazać to zachowanie.

Jeśli jeszcze tego nie zrobiłeś, możesz użyć build-helper-maven-plugin, aby dodać folder filtrów jako lokalizację zasobów.

Konfiguracja zrobić tak wygląda następująco:

<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

Dla mnie brzmi to trochę dziwne, aby umieścić plik właściwości w src/main/filters jeśli nie planujesz używać ten plik jako ... filtr. Jeśli ten plik jest używany jako standardowy zasób testowy, dlaczego nie umieścisz go w src/test/resources? Jeśli chcesz filtrować niektóre pliki zasobów, dlaczego po prostu tego nie zrobisz i nie użyjesz przefiltrowanych zasobów? Spodziewam się zobaczyć coś takiego:

<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> 

Może brakuje mi czegoś, ale myślę, że mieszasz niektóre koncepcje.W twoim przypadku (i jeśli dobrze zrozumiałem, co próbujesz zrobić), użyłbym profili i filtrów do zarządzania wieloma środowiskami. Rzucić okiem na:

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