 | As of version 0.9.4 plugin is always using the same output folders as Maven. See this dev-list thread for more details. |
Interesting use cases
- JDT build scrubs output folder, including filtered resources
- Source classes generated by Maven
- JUnit test classpath must put test classes/resources infront of other classpath entries
- One project, multiple modules
Sample project layouts
Simple project
project/
target-eclipse/
classes/
eclipse-classes is JDT output folder.
Project with generated sources or resources
project/
target-eclipse/
classes/
target/
generated-sources/
Sources are generated under target/generated-sources as usual, but compiled .class files are put under target-eclipse/.
Project with tests
project/
target-eclipse/
classes/
test-classes/
Separate target-eclipse/test-classes so we can reorder junit test classpath.
Project with resource filtering
project/
target-eclipse/
classes/
Filtered resources are put under target-eclipse/classes.
By moving resources and test-resources out of target, we'll be breaking unit tests that use new File("target/test-classes/foo.properties") to access these resources (thanks Brian for pointing this out).
Though that is a really bad practice and those tests should be using getClass().getResource("foo.properties") instead of assuming hard coded paths.
Multiple modules
project/
module1/
module2/
target-eclipse/
classes/
Sources from all modules are compiled into the same output folder eclipse-classes.
This layout does not allow resources and classes with the same name in multiple modules
Pros for collocating Eclipse and Maven build output folders
- Tests can rely on file system paths to access resources they need. (note that this a bad practice, as the whole point of copying resources under target/*classes is to make them available on classpath)
- Slightly better compilation performance when switching between Eclipse and mvn.
Cons for collocating Eclipse and Maven build output folders
- mvn clean deletes Eclipse build output folder that confuses JDT (number of Refresh, Project/Clean is required to recover)
- Eclipse and mvn may not be able to detect classes needed to recompile. From experience, such problems are extremely difficult to debug resulting in routing use of mvn clean and Project/Clean "just to be sure" (in other words, compilation time is actually much longer)
- resource filtering is trickier to support as JDT tends to "scrub" output folders
- Eclipse produces .class files even for classes with compilation errors. Such partially compiled classes may end up packaged into maven artifacts as mvn considers them up-to-date.