Bugzilla – Full Text Bug Listing
| Summary: | Project build output from src/test/resources is added to Java classpath for non-test executions | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Jonathan Cone <cone0010> |
| Component: | m2e | Assignee: | Project Inbox <m2e.core-inbox> |
| Status: | CLOSED INVALID | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | igor, sebtardif, stanio, stevemash |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Jonathan Cone
Note, the test case provided is contrived to illustrate the problem. This is occurring for a web application with multiple projects. When the application is deployed to Tomcat using WTP, its picking up the wrong properties from resources in the test folder subtree of dependent projects. Please attach complete standalone sample project and provide steps to reproduce the problem. FYI, expected runtime and test runtime classpath is described in [1]. I am not aware of any problems in this area and unit test coverage is pretty good actually [2]. [1] https://docs.sonatype.org/display/M2ECLIPSE/Runtime+classpath [2] https://github.com/sonatype/m2e-core-tests/blob/master/org.eclipse.m2e.tests/src/org/eclipse/m2e/tests/ClasspathProviderTest.java (In reply to comment #2) Igor in [1] does it only ever use src/test/resources or does it inspect the test-resources configuration in the POM? to determine which things to place _before_ the src/main things when building the classpath? For example, we have addition resources and test-resources folders: src/main/config src/test/config and would like the test/config to override main/config -- this doesn't seem to be respected right now -- but I haven't nailed down whether the problem is a consequence of the JDT issue you refer to in [1] or not. m2e uses test source and resource folders as configured in pom.xml. All test sources and resources get compiled to the same test output folder (i.e. target/test-classes by the default) and this output folder is expected to be placed on test runtime classpath before main output folder when the user utn tests using RunAs->JUnitTest on a Maven project or one of its resources. m2e injects special classpath provider, i.e. logic that calculates runtime classpath, into RunAs->JUnitTest (always) and RunAs->JavaApplication (when it can detect the main class comes form test source folder) launch configurations associated with Maven projects. m2e core does not apply test classpath calculation logic to other launch configuration types, but you need to ask m2e-wtp developers if there is Maven test classpath support in m2e-wtp. Thanks for the reply Igor. I know that the author of this bug was referring to WTP but my question was specifically about the java launch profile so thanks for the answer. So I need to do a little more digging to find out the source of my problem as (per your description) this shouldn't be a problem. What I _do_ notice is that if I re-arrange my source folders (which src/test/resources, src/main/resources, etc. are all source folders) in the Project -> Exports so that they are ordered as: src/test/resources src/test/config src/test/java src/main/resources src/main/config src/main/java then everything works -- however, after running maven -> update project configuration, m2e re-orders the source folder exports as: src/main/resources src/main/config src/main/java src/test/resources src/test/config src/test/java and now it doesn't work. I have to go manually "revert" the .classpath file from svn to re-apply my original ordering. I wouldn't care of course about what order is in the eclipse project configuration so long as the run configuration classloader looked up as described in your description. (specifically i am oredering them like this because i have a "test time" properties file in src/test/config that overrides a file of the same name with my prod values in src/main/confg) Sorry I don't mean to hijack this bug with my problem, but it seemed relevant. Closing old/stale bugreports. |