Repository navigation
Multi-Root Workspace with two Maven projects uses wrong pom dependencies #623
Description
VS Code 1.31.1 - Java Test Runner 0.14.0 - Maven for Java 0.14.2
I have two Maven Projects, each with UnitTests. If I open them individually all Tests run without problems. If I open them in a multi-root workspace and run Tests of the second Project, it seems to try and run the Tests with the dependencies of the first Project. The Projects use different Spring versions and the Testrunner tries to run the Tests of the second project using the Spring-Version from the first Project.
What is expected:
Running Tests in a Multi-Root Workspace project with several Maven Projects should use the pom Dependencies of the Project where the Test is located just as if the Root was Opened alone as an individual project.
Reacted by Cenk Altı
Activity
jdneo commentedon Feb 18, 2019
Falco (@falco467) Thank you for reporting the issue to us.
May I ask if it is possible for you to share a sample project for us to repro this issue? This will make it much easier to investigate the problem.
falco467 commentedon Feb 18, 2019
mavenTest.zip
I have created a minimal example Workspace to reproduce the error.
The error seems to only happen, if the projects depend on each other:
Project1 has old version of dependency.
Project2 has Project1 as dependency and newer version of the library as dependency.
Testrunner in Project2 somehow loads the old version of the library in multi-root workspace.
jdneo commentedon Feb 19, 2019
Falco (@falco467) Thank you! I'll take a look.
jdneo commentedon Feb 25, 2019
Falco (@falco467) The root cause looks like the classpath resolved by JDT is wrong. It treats the
oldGuavaas a project instead of dependency.I'll do some more investigation to see if it is possible to implement a method to resolve the classpath instead of calling
JavaRuntime.computeDefaultRuntimeClassPath(project)xhawk18 commentedon Apr 18, 2019
fixed ?
yaohaizh commentedon Apr 18, 2019
Sheng Chen (@jdneo) What's the status
jdneo commentedon Jun 17, 2019
Update:
looks like the
JavaRuntime.computeDefaultRuntimeClassPath(project)will use DFS to resolve the dependency which is not the case in Maven. Seems the Java debugger has the same problem and Jinbo Wang (@testforstephen) has provided a solution in microsoft/java-debug#281. I will try and see if that change can solve this issue.