Expose 'Update Project' to more places

[jdneo]

Quoting user's feedback:

Add a command to rebuild the project the current active file is part of. Currently, I have to open the pom file and run "Java: Update Project". It would be nice to be able to run that command without having to go open the pom file first.

a command that brings up a list of projects within the workspace, and allows me to select which project to update would be nice. Sometimes I need to update multiple projects (for example, projects that generate code frequently get out of sync) but not all of them. Currently, I either have to choose to update all projects and take a break while that happens, or open the POM file for each project needing to be updated and run "Java: Update Project". Both options kinda suck, so improving this experience would be awesome!

[jdneo]

Ideas:

• Expose update project action to more places (for example, can be invoked in Java Project explorer, Maven explorer, Gradle explorer)
• Allow users to select projects to update, and not limit the trigger files to pom and gradle files. (as long as the language server can find the belonging project with the uri string).

[rgrunber]

As discussed, for the labeling of the action, maybe Update Project Configuration makes more sense. Update Configuration (if you feel "Project" is implied by the context ?

The goal is to make it clear that this isn't an action you need to perform unless a configuration change to build files has been made.

[jdneo]

The goal is to make it clear that this isn't an action you need to perform unless a configuration change to build files has been made.

Yes, the current Update Project seems not clearly infers the meaning of the command. Update Project Configuration can be a candidate. (Only one concern: I'm not quite sure if users can connect the project configuration with the build files, will they think it's some other kind of configurations?)

---

By the way, I have some new findings:

Auto Update

M2E does have the auto update feature enabled by default. If I added a new dependency and save the pom.xml, new types are available in the completion list.

But for Buildship it still needs an update to include new dependency.

Based on that, I think the change that pop up project lists when users are editing java files still makes sense. Considering when users are working on a Gradle project, he introduced a new dependency in build.gradle and forget to update. He might realize that when he cannot find the new types in the completion list, then he can trigger an update from command palette directly.

Our recommend choice for configuration update

I found that currently our recommend choice for configuration update is Never, which surprises me. (I guess we don't have any recommend at first, but after some version of VS Code, it will always highlight the first item?)

Anyway, here I think at least we should highlight Now or even Always.

[jdneo]

The last remaining thing is about the naming.

Below is how it is called in other IDEs

	Maven	Gradle
Eclipse	Update Project	Refresh Gradle Project
IntelliJ	Reload Project	Reload Gradle Project

They all have one thing in common: A 'sync' icon is used for the command:

Eclipse Gradle

Eclipse Maven

IntelliJ Gradle

IntelliJ Maven

So Reload or Refresh might be a better one?

[rgrunber]

@fbricon , thoughts ? Does VS Code itself have a preferred terminology ?

[fbricon]

I don't have a strong opinion. We can do Reload project, to align with the leader in Java IDEs

[jdneo]

This issue has been addressed from different aspects, which are

• Support project selection: Support project update selection #2513
• Change the order of the options: Change the order for configuration updating options eclipse-jdtls/eclipse.jdt.ls#2135
• Rename 'Update Project' to 'Reload Project': Rename 'Update Project' to 'Reload Project' #2527

The next steps are exposing it from other explorers, like Maven/Gradle/Java Project explorers. Which can be done in the related extensions separately. So this issue can be closed.