Maven plugin not always activated in large multi-root workspace #881

benzman81 · 2022-09-27T08:12:54Z

Describe the bug
Hi, we have an issue on different developer notebooks that after re-/starting vscode the maven plugin is not working.

To Reproduce
Steps to reproduce the behavior:

Re-/start vscode
Go to explorer
No maven view in explorer visible and maven favorites do not work

Expected behavior
Maven view in explorer is visible and maven favorites do work as expected.

Environments (please complete the following information as much as possible):

OS: Windows 10 Version 20H2
VS Code version: 1.71.2
Extension version: 0.39.0

Screenshots

Missing maven view in explorer:

Error executing maven favorites;

Additional context
If we go to the extension and open the maven plugin, then disable and enable the plugin again without clicking reload button in the resulting vs code warning popup, then the maven view in explorer is visible and maven favorites start working until next restart of vscode.

The text was updated successfully, but these errors were encountered:

Eskibear · 2022-09-27T08:40:02Z

That seems like vscode-maven extension was not activated.

Below is it's activation events:

vscode-maven/package.json

Lines 38 to 63 in c21885b

    
           "activationEvents": [ 
        
             "workspaceContains:**/pom.xml", 
        
             "onCommand:maven.explorer.refresh", 
        
             "onCommand:maven.goal.clean", 
        
             "onCommand:maven.goal.validate", 
        
             "onCommand:maven.goal.compile", 
        
             "onCommand:maven.goal.test", 
        
             "onCommand:maven.goal.test-compile", 
        
             "onCommand:maven.goal.package", 
        
             "onCommand:maven.goal.verify", 
        
             "onCommand:maven.goal.install", 
        
             "onCommand:maven.goal.site", 
        
             "onCommand:maven.goal.deploy", 
        
             "onCommand:maven.goal.custom", 
        
             "onCommand:maven.goal.execute", 
        
             "onCommand:maven.goal.execute.fromProjectManager", 
        
             "onCommand:maven.project.effectivePom", 
        
             "onCommand:maven.project.openPom", 
        
             "onCommand:maven.archetype.generate", 
        
             "onCommand:maven.archetype.update", 
        
             "onCommand:maven.history", 
        
             "onCommand:maven.plugin.execute", 
        
             "onCommand:maven.project.addDependency", 
        
             "onCommand:maven.project.excludeDependency", 
        
             "onView:mavenProjects" 
        
           ],

then the maven view in explorer is visible and maven favorites start working until next restart of vscode.

It's strange. As long as you have a pom.xml in your workspace, this extension should be activated automatically. You can check Ouput channel "Log (Extension Host)". There you have logs about extension activation.

benzman81 · 2022-09-27T14:32:14Z

@Eskibear I found this log entry:
[2022-09-27 10:04:11.096] [exthost] [info] Not activating extension 'vscjava.vscode-maven': Timed out while searching for 'workspaceContains' pattern **/pom.xml

We use a workspace with multiple folders.

benzman81 · 2022-09-27T15:30:03Z

@Eskibear after some research in vscode, do I understand it correctly, that it is by design, that vscode only tries the search 7 seconds? In a multi root workspace this is often insufficient, as in my case where not all folders are maven plugins. Is the setting maven.excludedFolders helping here somehow? Because that is what I would need then. Otherwise workspaceContains with pattern **/pom.xml is maybe pretty aggressive. Maybe just searching by pom.xml in the root of a workspace folder is better?

Eskibear · 2022-09-28T02:35:02Z

Is the setting maven.excludedFolders helping here somehow?

It will help if you provide some folders to exclude. This setting was introduced mainly to skip specific folders in polyglot projects like node_modules, somehow improving the performance. As a workaround for the moment, you can set maven.excludedFolders per workspace root, in those non-maven root folders, you directly skip the scanning.

Maybe just searching by pom.xml in the root of a workspace folder is better?

No, it's not going to work. It's common to place multiple maven projects flat under a root folder. And some developers are used to open that root folder, although we do suggest them to open each project as a workspace root folder.
If it's indeed too aggressive, one approach is following what we did for Java extension recently, only to search 2 levels of folders for pom.xml. But that would introduce a bahavior change, and I don't know if there would be developers coming to complain that it's too "conservative".

Eskibear · 2022-09-28T02:38:11Z

BTW, can you share which folder of you non-maven projects contains large number of files? Another thing we can do for sure is, to add the typical folder pattern into maven.excludedFolders as a default value.

benzman81 · 2022-09-28T08:55:35Z

@Eskibear ok, based on what I investigated now is, that vscode-maven is not the only plugin that doesnt get activated:

[2022-09-28 08:33:13.782] [exthost] [info] Not activating extension 'redhat.fabric8-analytics': Timed out while searching for 'workspaceContains' pattern **/package.json,**/pom.xml,**/requirements.txt,**/go.mod
[2022-09-28 08:33:13.782] [exthost] [info] Not activating extension 'redhat.java': Timed out while searching for 'workspaceContains' pattern */pom.xml,*/build.gradle,*/settings.gradle,*/build.gradle.kts,*/settings.gradle.kts,*/.classpath
[2022-09-28 08:33:13.782] [exthost] [info] Not activating extension 'vscjava.vscode-java-pack': Timed out while searching for 'workspaceContains' pattern */pom.xml,*/build.gradle,*/settings.gradle,*/build.gradle.kts,*/settings.gradle.kts,*/.classpath
[2022-09-28 08:33:13.782] [exthost] [info] Not activating extension 'vscjava.vscode-java-test': Timed out while searching for 'workspaceContains' pattern */pom.xml,*/build.gradle,*/settings.gradle,*/build.gradle.kts,*/settings.gradle.kts,*/.classpath
[2022-09-28 08:33:13.783] [exthost] [info] Not activating extension 'vscjava.vscode-maven': Timed out while searching for 'workspaceContains' pattern **/pom.xml

Now, since I wanted to try a simple solution, I added a pom.xml in every root folder of the project in my multi root workspace so that the structure iis like this:

Project a
- folder and files of project
- pom.xml
Project b
- folder and files of project
- pom.xml
Project c
- folder and files of project
- pom.xml
Project {n}
- folder and files of project
- pom.xml

The issue remains supprisingly the same. I expected now, that a pom.xml will be found right away, but it isnt.

Since I cannot share the project, here is a list with number of files and folders of the workspace that has the problem everytime:

c:\git\project 01 (maven project with pom.xml)              - 1.126 files and 371 folders
c:\git\project 02 (maven project with pom.xml)              - 950 files and 333 folders
c:\git\project 03 (maven project with pom.xml)              - 10.444 files and 913 folders
c:\git\project 04 (maven project with pom.xml)              - 8.149 files and 999 folders
c:\git\project 05 (maven project with pom.xml)              - 1.217 files and 430 folders
c:\git\project 06 (maven project with pom.xml)              - 3.182 files and 516 folders
c:\git\project 07 (maven project with pom.xml)              - 2.249 files and 487 folders
c:\git\project 08 (maven project with pom.xml)              - 16.200 files and 3.079 folders
c:\git\project 09 (NOT maven project but with fake pom.xml) - 791 files and 267 folders
c:\git\project 10 (NOT maven project but with fake pom.xml) - 487 files and 224 folders
c:\git\project 11 (NOT maven project but with fake pom.xml) - 1.890 files and 311 folders
c:\git\project 12 (NOT maven project but with fake pom.xml) - 1.970 files and 273 folders
c:\git\project 13 (NOT maven project but with fake pom.xml) - 1.705 files and 328 folders
c:\git\project 14 (NOT maven project but with fake pom.xml) - 18.737 files and 2.529 folders
c:\git\project 15 (maven project with pom.xml)              - 1.125 files and 4444 folders
c:\git\project 16 (maven project with pom.xml)              - 1.143 files and 301 folders
c:\git\project 17 (maven project with pom.xml)              - 1.678 files and 316 folders
c:\git\project 18 (maven project with pom.xml)              - 486 files and 235 folders
c:\git\project 19 (maven project with pom.xml)              - 769 files and 277 folders
c:\vscode-workspaces (maven project with pom.xml)           - 8 files and 0 folders

One more thing I tried is to run a simple js script using glob pattern and measure execution time. Here's the script:

const glob = require("glob");
console.time("run");
const folders = [
"c:/git/project 01",
"c:/git/project 02",
"c:/git/project 03",
"c:/git/project 04",
"c:/git/project 05",
"c:/git/project 06",
"c:/git/project 07",
"c:/git/project 08",
"c:/git/project 09",
"c:/git/project 10",
"c:/git/project 11",
"c:/git/project 12",
"c:/git/project 13",
"c:/git/project 14",
"c:/git/project 15",
"c:/git/project 16",
"c:/git/project 17",
"c:/git/project 18",
"c:/git/project 19",
"C:/vscode-workspaces"];

let current = 0;
for (const folder of folders) {
	console.log(folder);
	glob(folder+"/.*/pom.xml", function (err, files) {
	  if (err) {
		console.log(err);
	  }
	  console.log(files);
	  current++;
	  if(current === folders.length) {
		console.timeEnd("run");
	  }
	});
}

Here's the result for each pattern I tried:

**/pom.xml = 5.057s
/pom.xml = 35.841ms
.*/pom.xml = 55.834ms

Maybe that helps a bit, but since the plugin redhat.java already uses a non aggressive pattern it fails, too :-(

Eskibear · 2022-09-29T16:31:48Z

Thanks for the detailed information.

I think we might revisit the activation events and find ways to optimize for such cases.
/cc @jdneo @testforstephen

gian1200 · 2023-07-29T00:45:21Z

I have a similar (if not same) scenario. In my case it's not with a "large multi-root workspace". It's with a worksapce with 6 smalls projects (5 java/maven and 1 nodejs).

As a workaround, I found that right clicking any pom.xml and executing "Show effective POM" wakes up the extension (including the MAVEN view).

Eskibear · 2023-08-05T08:12:31Z

As long as you have a pom.xml in your workspace, this extension should be activated automatically. You can check Ouput channel "Log (Extension Host)". There you have logs about extension activation.

@gian1200 fyi.

gian1200 · 2023-08-07T16:58:49Z

It seems to be related to what was mentioned at #881 (comment)

I opened and closed VSCode multiple times and the extension activated in some of them. When it didn't, it was due to a timeout, after 5-7 seconds (?).

2023-08-07 11:39:18.280 [info] Extension host with pid 28272 started
...
2023-08-07 11:39:18.919 [info] ExtensionService#_doActivateExtension redhat.java, startup: true, activationEvent: 'workspaceContains:pom.xml'
2023-08-07 11:39:19.604 [info] ExtensionService#_doActivateExtension vscjava.vscode-java-dependency, startup: true, activationEvent: 'workspaceContains:pom.xml'
2023-08-07 11:39:19.671 [info] ExtensionService#_doActivateExtension vscjava.vscode-java-pack, startup: true, activationEvent: 'workspaceContains:pom.xml'
2023-08-07 11:39:19.725 [info] ExtensionService#_doActivateExtension vscjava.vscode-java-debug, startup: true, activationEvent: 'workspaceContains:pom.xml', root cause: vscjava.vscode-java-test
...
2023-08-07 11:39:25.797 [info] Not activating extension 'vscjava.vscode-gradle': Timed out while searching for 'workspaceContains' pattern **/gradlew,**/gradlew.bat
2023-08-07 11:39:25.797 [info] Not activating extension 'vscjava.vscode-java-dependency': Timed out while searching for 'workspaceContains' pattern */pom.xml,*/build.gradle,*/settings.gradle,*/build.gradle.kts,*/settings.gradle.kts,*/.classpath
2023-08-07 11:39:25.797 [info] Not activating extension 'vscjava.vscode-java-pack': Timed out while searching for 'workspaceContains' pattern */pom.xml,*/build.gradle,*/settings.gradle,*/build.gradle.kts,*/settings.gradle.kts,*/.classpath
2023-08-07 11:39:25.797 [info] Not activating extension 'vscjava.vscode-java-test': Timed out while searching for 'workspaceContains' pattern */pom.xml,*/build.gradle,*/settings.gradle,*/build.gradle.kts,*/settings.gradle.kts,*/.classpath
2023-08-07 11:39:25.797 [info] Not activating extension 'vscjava.vscode-maven': Timed out while searching for 'workspaceContains' pattern **/pom.xml
...
2023-08-07 11:39:29.823 [warning] [redhat.java] Accessing a resource scoped configuration without providing a resource is not expected. To get the effective value for '[java]', provide the URI of a resource or 'null' for any resource.
2023-08-07 11:39:30.353 [info] ExtensionService#_doActivateExtension redhat.vscode-microprofile, startup: true, activationEvent: 'workspaceContains:**/src/main/resources/application.properties,**src/main/resources/META-INF/microprofile-config.properties,**/src/main/resources/application.yaml,**/src/main/resources/application.yml'
2023-08-07 11:39:30.849 [info] ExtensionService#_doActivateExtension vscjava.vscode-java-test, startup: true, activationEvent: 'workspaceContains:pom.xml'
2023-08-07 11:39:32.742 [warning] [redhat.java] Accessing a resource scoped configuration without providing a resource is not expected. To get the effective value for '[java]', provide the URI of a resource or 'null' for any resource.

sa-schiefer · 2024-04-09T08:38:29Z

This remains being an issue and happens even in very small projects.
For example, a simple, single Azure Function app can already be affected.

The timeout-based logic doesn't seem to properly work in workspaces with a lot of extensions, especially for Java projects which are slow to fully load with the language server and whatever else is needed.

The "show effective pom" trick is luckily still working, but I'd love to be able to configure this timeout and set it to 30s or so for startup.

Eskibear self-assigned this Sep 27, 2022

Eskibear added the discussion label Sep 28, 2022

Eskibear changed the title ~~Maven plugin not working after restart vscode~~ Maven plugin not always activated in large multi-root workspace Sep 28, 2022

Eskibear added this to the backlog milestone Sep 29, 2022

Eskibear mentioned this issue Oct 11, 2022

Maven for Java extension not activated even workspace contains pom.xml file #885

Closed

Eskibear added the external label Mar 22, 2023

Eskibear assigned testforstephen and unassigned Eskibear Aug 14, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Maven plugin not always activated in large multi-root workspace #881

Maven plugin not always activated in large multi-root workspace #881

benzman81 commented Sep 27, 2022

Eskibear commented Sep 27, 2022

benzman81 commented Sep 27, 2022

benzman81 commented Sep 27, 2022

Eskibear commented Sep 28, 2022

Eskibear commented Sep 28, 2022

benzman81 commented Sep 28, 2022

Eskibear commented Sep 29, 2022

gian1200 commented Jul 29, 2023

Eskibear commented Aug 5, 2023

gian1200 commented Aug 7, 2023

sa-schiefer commented Apr 9, 2024

Maven plugin not always activated in large multi-root workspace #881

Maven plugin not always activated in large multi-root workspace #881

Comments

benzman81 commented Sep 27, 2022

Eskibear commented Sep 27, 2022

benzman81 commented Sep 27, 2022

benzman81 commented Sep 27, 2022

Eskibear commented Sep 28, 2022

Eskibear commented Sep 28, 2022

benzman81 commented Sep 28, 2022

Eskibear commented Sep 29, 2022

gian1200 commented Jul 29, 2023

Eskibear commented Aug 5, 2023

gian1200 commented Aug 7, 2023

sa-schiefer commented Apr 9, 2024