Maven projects do not have access to dependencies from the test scope

[clembo590]

Environment

• Operating System: macos 12.0.1
• JDK version: 1.8
• Visual Studio Code version: 1.69.1
• Java extension version: java extension pack v0.24.0

Steps To Reproduce

I have created a public repo so that the issue is easily reproducible:

step1: clone this repo:

git clone https://github.com/clembo590/issues.git --branch vs_code_does_not_build

step2: run mvn clean install
-->no issue

step 3: "import the project in vscode"
I get the error
The project was not built since its build path is incomplete. Cannot find the class file for org.slf4j.Logger. Fix the build path then try building this project

[jdneo]

I can reproduce it. @snjeza is this related with the m2e migration?

[snjeza]

I can reproduce the issue in the m2e 1.x . You can try the following patch:

diff --git a/pom.xml b/pom.xml
index 9067c56..c640ed3 100644
--- a/pom.xml
+++ b/pom.xml
@@ -10,6 +10,7 @@
   <properties>
     <java.version>1.8</java.version>
     <feign.version>10.2.0</feign.version>
+    <m2e.disableTestClasspathFlag>true</m2e.disableTestClasspathFlag>
   </properties>
 
   <dependencies>

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=537578

[clembo590]

@snjeza thank you for the suggestion and for the great work you guys are doing.
But does it feel OK to you that I would modify the code of my project in order for vscode to be able to work ?
To me this is not ok... Unfortunately I work for a big company where code is reviewed and we do not add code that should not be there.
Any plan on fixing this issue ? (I must say that I have been working in java in vscode for like 9 months and you guys are doing great but there are still some issues that really need to be fixed in order for java professionals to be able to use vscode instead of intellij. I posted several issues but it takes time to report those issues and if you decide to not fix it then I have wasted my time and yours.)

[snjeza]

@clembo590 you can try the following:

• create the usersettings.xml file

<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
    <profiles>
        <profile>
            <id>m2e</id>
            <activation>
                <property>
                  <name>m2e.version</name>
                </property>
            </activation>
            <properties>
                <m2e.disableTestClasspathFlag>true</m2e.disableTestClasspathFlag>
            </properties>
        </profile>
    </profiles>
</settings>

• add the following property to your settings.json

"java.configuration.maven.userSettings": "<path_to_usersettings.xml>",

• reload your project

[clembo590]

@snjeza thank you for this solution. (and sorry for the delay in the response: I got a baby and kind of was not focused on vscode anymore). Your solution: it does work indeed.

But Is there any plan to actually fix the issue so that a developper would not have to perform

1. the creation of a maven user setting file specifcally for vscode....
2. editing the settings.json file

The main problem I see here is that if a developpers has a "maven settings.xml" provided by a company with other profiles and mirrors etc... then you also have to put all those profiles/mirrors in the file you talked about...

Maybe instead of this:
Could we have a property called "disableTestClasspathFlag" that would be editable from vscode settings.json ?
Also why is this disableTestClasspathFlag property no set to true by default ? (I mean the example I posted is really the most basic thing a developper can create)

[snjeza]

Also why is this disableTestClasspathFlag property no set to true by default ? (I mean the example I posted is really the most basic thing a developper can create)

It is an upstream m2e property

Could we have a property called "disableTestClasspathFlag" that would be editable from vscode settings.json ?

Yes, we could.
cc @fbricon @rgrunber

[rgrunber]

At the very least we should include a setting for this. I'm just wondering whether we can go as far as enabling it by default.

We might need to consider how Gradle projects behave and whether having a behaviour that might be different is desired.