Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 355816 - classifier=tests is ignored by workspace dependency resolver
Summary: classifier=tests is ignored by workspace dependency resolver
Status: CLOSED WONTFIX
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: m2e (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-25 07:04 EDT by Frank Jakop CLA
Modified: 2021-04-19 13:23 EDT (History)
1 user (show)

See Also:


Attachments
testproject to reproduce the below errors (23.73 KB, application/octet-stream)
2011-08-25 07:04 EDT, Frank Jakop CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Jakop CLA 2011-08-25 07:04:55 EDT
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
Comment 1 Frank Jakop CLA 2011-08-25 07:08:59 EDT
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
Comment 2 Igor Fedorenko CLA 2011-08-25 08:26:25 EDT
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
Comment 3 Frank Jakop CLA 2011-08-25 08:52:12 EDT
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.
Comment 4 Igor Fedorenko CLA 2011-08-25 09:06:51 EDT
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
Comment 5 Igor Fedorenko CLA 2012-05-21 10:52:16 EDT
Closing old/stale bugreports.
Comment 6 Denis Roy CLA 2021-04-19 13:23:13 EDT
Moved to https://github.com/eclipse-m2e/m2e-core/issues/