Bugzilla – Full Text Bug Listing
| Summary: | classifier=tests is ignored by workspace dependency resolver | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Frank Jakop <frank.jakop> | ||||
| Component: | m2e | Assignee: | Project Inbox <m2e.core-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | igor | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
The precise version of m2e used is 1.0.100.20110804-1717 Eclipse 3.7 eclipse.buildId=I20110613-1736 Windows XP and/or Windows 7 JDK 1.6.0_25 I am not too familiar with maven.test.classpath... isn't it something specific to maven-ant-run plugin? If so, m2e is not expected and in fact cannot use this variable for compilation of test classes inside eclipse. Respecting test scope inside workspace is a trickier question because generally Eclipse treats each workspace project as one classpath entry. m2e can pass properly scoped dependencies to Maven plugins executed inside workspace (this requires relatively small change to [1]), but changing JDT to respect test scope during compilation is something outside of m2e control and you need to talk to JDT team about that. Also, bug 352962 describes related problem that affects test dependency resolution for Maven builds executed in external JVM with workspace resolution enabled. [1] http://git.eclipse.org/c/m2e/m2e-core.git/tree/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/project/registry/EclipseWorkspaceArtifactRepository.java?id=milestones/1.0.100/1.0.100.20110804-1717 Ok, if I understand you right, JDT can not use multiple classpathes as input while compiling. As for "maven.test.classpath", it's generated inside antrun-plugin by StringUtils.join( mavenProject.getTestClasspathElements().iterator(), File.pathSeparator ); so if the MavenProject gets the same classpath handed over by m2e as JDT does, it would solve problem #1 for us, because we only had too much classpath entries, for the above example it would be some_dir\master\module_b\target\test-classes; some_dir\master\module_b\target\classes; some_dir\master\module_a\target\test-classes; some_dir\master\module_a\target\classes The question for me is now, where does the MavenProject-object in the mojo gets its classpath set? Is this done by m2e? If so, can m2e set the same classpath as passed to JDT? You also talk about JVMs "outside eclipse". I know no way to configure eclipse not to use some external JVM, configured under "Installed JREs". If there is any, please let me know. JDT classpath and mavenProject.getTestClasspathElements() and calculated independently off the same dependency information. The code I referenced is involved in calculation of mavenProject.getTestClasspathElements() and it can be extended to handle classifier=test properly. Also note that using ant-run plugin for code instrumentation will almost certainly have bad side-effects described in http://wiki.eclipse.org/M2E_plugin_execution_not_covered Closing old/stale bugreports. |
Created attachment 202139 [details] testproject to reproduce the below errors We recently added the antrun-plugin to the lifecycle-phase process-test-classes (for do some bytecode-enhancements). After we got some errors there, we found out, that m2e was not passing/building the variable "maven.test.classpath" correctly. Here's our setup (test project attached): One master with 2 modules master \-module_a \-module_b Module_b has a test-scope dependency to module_a:tests (because some mock/helper is located therein) We echoed the value of "maven.test.classpath" while executing the antrun-plugin and expected it for module_b to be some_dir\master\module_b\target\test-classes; some_dir\master\module_b\target\classes; some_dir\master\module_a\target\test-classes Executing "mvn clean process-test-classes" in master from the console produced the expected result. Now looking at outputs from execution of m2e it was - surprise D:\Eclipse Workspaces\Indigo_1\master_hier\master\module_b\target\test-classes; D:\Eclipse Workspaces\Indigo_1\master_hier\master\module_b\target\classes; D:\Eclipse Workspaces\Indigo_1\master_hier\master\module_a\target\classes Neither we did include module_a:jar in module_b's dependencies, nor did the inclusion of module_a:tests get honoured by m2e. Ok, getting to that, let's get a little more confused. When I change the dependency from module_a:tests to module_a:jar the compile of a test class in module_b fails on console build, because the test class in module_b needs a class from module_a:tests. When the same project is built inside eclipse with m2e there is no failure. This leads us to 2 conclusions: 1) m2e does not honour test scope correctly 2) "maven.test.classpath" is not used for compilation of test classes inside eclipse Thus this is a real blocker for us, we would highly appreciate a fix. We also would gladly test some dev/unstable versions of m2e. Regards Frank