tags:

views:

27

answers:

3

I have a simple java maven project. One of my classes when executing needs to load an xml configuration file from the classpath. I dont want to package such xml file when producing the jar but I want to include a default xml file in a zip assemply under a conf subfolder and I also want this default xml to be available in the unit tests to test against it. As I see it there are 2 possible places of this default xml:

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

Both solutions demand special pom actions: In solution 1, I get the auto copy to target folder during build which means it is available in testing but I also get it in the produced jar which i dont want. In solution 2, I get the jar as I want it(free of the xml) but I manually have to copy the xml to the target folder to be available for testing. (I dont want to add src's subfolders in test classpath. I think it is bad practice).

The question is what is the best solution of the two? If the correct is 2, what is the best way to copy it to target folder? Is there any other solution better and more common than those two?

(I also read http://stackoverflow.com/questions/465001/where-should-i-put-application-configuration-files-for-a-maven-project but I would like to know the most "correct solution" from the "convention over configuration" point of view and this link provides some configuration type solutions but not any convention oriented. Maybe there isnt one but I ask anyway. Also the solutions provided include AntRun plugin and appAssembler plugin and I wonder if I could do it with out them.)

+1  A: 

You could place it in src/test/conf/default.xml. Your testclasses can find it, but it wont be packaged using the standard method.

With an additional assembly you can package it from there. That step is always necessary.

A different solution could be to create a separate maven module and place it in /src/main/resources/conf/... .Then make this jar a test dependency. You do not need to do any special plugin configuration, but I think it is overkill for a single file.

Peter Tillemans
The thing i dont like with this solution is that the assembly producing the zip will need to get it from src/test/conf and this xml is not only a test file. I assume your proposed solution is the same if I instead put it in src/main/conf? From there it is also visible to tests from the target/classes folder instead of target/test-classes. Is it wrong to do tests that get data from target/classes or should they depend only in target/test-classes?
Paralife
+1  A: 

The question is what is the best solution of the two? If the correct is 2, what is the best way to copy it to target folder? Is there any other solution better and more common than those two?

Since you want that file to be copied to the target/classes folder, it has somehow to be considered as a resource (so either put in under src/main/resources or declare src/main/conf as resource directory). And if you don't want it in the final jar, configure the Maven JAR Plugin to exclude it:

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

For the assembly part, assembly descriptors are pretty flexible so it should be possible to achieve what you want regardless of the choice. I'd suggest using the easiest setup though.

Pascal Thivent
+1  A: 

My solution was to use two profiles: Development (default) and Packaging

My default / section contains both src/main/resources and src/main/conf. I call this my Development profile, which is an implicit profile.

My packaging profile is an explicit profile which is defined under section. There under / I only mentioned src/main/resources. When I'm running my packaging script (we currently have this external to maven since its building an RPM out of our WAR), I'm running 'mvn install -Drpm' to activate my Packaging profile (rpm is the id for the Packaging profile.

If this wasn't clear enough, feel free to ask more questions.

Asaf Mesika