Just checking in case there's a good way to configure this for m2e in the POM, although my guess is no:
I have a project where, for the time being, I want to ensure that all the artifacts I build require only JDK 1.6.
Both my Eclipse and my Maven build server use JDK 1.7, and I do the usual things: configure the maven-compiler-plugin with source = target = 1.6, and enable animal-sniffer with the JDK 1.6 signatures. Given this, m2e configures the Eclipse projects to use JDK 1.6, so Eclipse immediately catches any mistaken attempts to use JDK 1.7+ functionality (e.g. diamond operator). So far, so good.
The problem is: one of the third-party libraries used by my JUnit tests requires JDK 1.7. This works OK in Maven builds (both under Eclipse/m2e and on my build server) because the JVM that they're using is 1.7. However, Eclipse Run As - JUnit Test uses the JDK 1.6 that has been autoconfigured for the project and then of course fails when it encounters the higher class-file format version.
What I need, I suppose, is a way to distinguish between the JDK version (1.6) that Eclipse should use for editing / compiling src/main/java and the JDK version (1.7) that it should use for executing src/test/java (I don't care too much which version it uses for editing / compiling src/test/java, although 1.6 would be preferable).
Presumably one way to do this is to tweak an Eclipse run configuration for the JUnit tests so that it explicitly uses JDK 1.7. Easy enough, but it starts to get a bit clunky if I want other developers to be able to check it out and have it "just work" -- so the ideal would be something that I could put in the POM (if necessary, in an m2e-specific profile).
(This is a multi-module project and so far the test-library-uses-JDK-1.7 issue only arises in one of the modules. I think that even a single-module project could have the same issue, although there might -- I'm not sure -- be solutions for the single-module project that don't extend to one or some modules in a multi-module project).
Thanks for any (perhaps obvious) approaches that I should have thought of but haven't.
