Improve the Java Dependency Explorer

[ccarv]

As someone who has used Eclipse and NetBeans, this view is simply much more efficient to work with when navigating a large Java project. Trying to navigate Java source paths is cumbersome.

I have tried to use the Java Dependency viewer solely to work with my projects but simple features like linting indicators and Git modifications are missing. I understand this would be overlapping functionality that of the default folder viewer but they are necessary for this view.

I am a new VSCode user trying to embrace this amazing IDE but find myself wanting to go back to NetBeans and or Eclipse for this specific reason.

[jdneo]

Thank you for your feedback @ccarv.

Actually we have received several different opinions from our users regarding to the dependency viewer.

• Some users hope the dependency viewer could be simplified to only show the dependencies, while leveraging the file explorer to navigate the sources.
• Some users (like you) hope the dependency viewer could be a centralized view to do all of the code navigations related works.

I have one question about this request. What do you think about the first choice? Will you accept it or not, why?

//cc @akaroml

[ccarv]

I feel like the first choice is already representative in its current state. It is straight forward, offers no context menu in any form, and purely informational with the ability of navigating source files (and seeing project dependencies).

I think perhaps the best way to approach this is defining a more narrow scope for the views, and even separating out functionality. This would leave everyone happy and provide options and might even make adoption easier.

Maybe a proposal for the following:

• Java Dependencies: This view is a detailed view of project dependencies, broken down by their groupId / artifactId. This would allow you to quickly identify dependencies.
• File Explorer: This viewer would continue to operate the same way.
• Package Explorer: A new view that would provide an alternative to File Explorer, and in my opinion, a much more sane way of navigating Java source files.

[ccarv]

Does VSCode provide any API's for tabulated views? Such that, one view is File Explorer (and perhaps default at first) and the second view would be the Package Explorer view. This would consolidate views that offer similar functionality.

Also, I apologize if I am not using the correct lingo. Please correct me.

[jdneo]

Does VSCode provide any API's for tabulated views?

No, it's not supported so far.

Maybe a proposal for the following: ...

Thank you for the suggestion. I like the idea! May I have a question about this suggestion - What makes it difficult to navigate Java source files through the File Explorer? Since now the File Explorer supports compact rendering

I guess it won't be that difficult to use it for navigation.

[ccarv]

Working with a single Java project isn't very difficult in VSCode. It is when you start working with large Java projects that the File Explorer breaks down; when you are having to bounce around from sub-module to sub-module. For example, in NetBeans / IntelliJ / Eclipse, the package explorer view breaks down source code by their FQDN, and also categorizes Java specific files like the pom.xml and src/main/resources. This makes it much easier to navigate a large Java projects, with many files (not just talking source files).

I find myself working with the pom.xml file quite a bit in newer projects. In VSCode, it is difficult to differentiate between pom.xml in a given project, since there are multiple. Take the following for example:

You may have not noticed but there are two pom.xml files in that view: the parent POM, and the child POM. Imagine working with two child module and the parent? There is so much noise (especially as a result of the Eclipse plugin), that it makes it very difficult to find Java specific files. A package explorer would provide the necessary filtering and also provide a means to navigate your source files efficiently.

Now, here is a view of NetBeans. I am looking at the same exact files I want to look at in VSCode in about 30% of the space.

[ccarv]

I suppose my real issue with the file explorer is that it does not filter out the noise. I could live without the package names, although I believe them to be very useful when working with large Java projects.

Eclipse and git contain a lot of noise completely unrelated to the compilation of a Java project, and as mentioned by other users, I find myself navigating with the Java Dependency viewer to find things.

I've worked with plenty of Java IDE's in multiple environments and teams, and you will find that most engineers will choose the package explorer.

[jdneo]

@ccarv Thank you for the great answers, learnt a lot! Quite agree about the example of pom.xml, I also have this this problem during my development.

I'll discuss this with my team.

[ccarv]

@jdneo No problem. And thank you guys for your efforts. I am enjoying VSCode and look forward to seeing more from your team.

I would love to contribute to the project, although I don't see any development guides. Does this repository accept PRs?

[jdneo]

@ccarv Sure thing! Please let me know if you meet any problems.

[jdneo]

Here are some update after syncing:

Some Facts Which Drive the Decision

• Given the limited space for the VS Code sidebar, too much expanded explorers will be annoying. We think an acceptable number of expanded explorers would be two.
• Now the nodes in the Dependency Explorer has a lot of duplications with other explorers. For example: document symbols are duplicated with the Outline Explorer

Step 1: Simplify the dependency viewer

As the following picture shows, the document symbols are duplicated:

So we will remove those nodes in the Dependency Viewer. Users can leverage the VS Code embedded outline explorer to see them.

Step 2:

We will sync with the VS Code team to see if it is possible for an extension to contribute some virtual nodes in the file explorer. This could be a good point to integrated the package view into one single explorer.

[ccarv]

@jdneo This looks good. Consolidating the views is key to creating a fluid user experience. So if I understand this correctly, step 2 is investigating whether you can integrate the package view within the file explorer?

Thank you for the update.

[jdneo]

step 2 is investigating whether you can integrate the package view within the file explorer?

Yes you are right. Will update here if we get any feedback from VS Code team.

Thanks.

[ccarv]

@jdneo Any movement on this?

[akaroml]

Allowing virtual nodes in File Explorer is a dangerous slope to go. The File Explorer could be easily broken with all 3rd parties tampering. I don't think we could expect vscode to enable that very soon.

[ccarv]

@akaroml What about an enhancement to the Java Dependency Viewer? As an alternative view to the file explorer, you could introduce features discussed in my OP. The delta is rather small.

For clarification:

• SCM operation color indicator (updated, added, and deleted)
• A section for Maven specific files (like the POM file)
• Context aware right click menu

This would offer a much cleaner view in comparison to the file explorer. There would be overlapping functionality that of the file explorer but again, this would be an alternative view.

[akaroml]

@ccarv Thanks for sharing thoughts.

If I may, the first item is to show the SCM status on the tree nodes like the File Explorer. It makes sense to me and we'll check the feasibility first. @jdneo

For the second one, can the Maven view help? The Maven view is another tree view introduced by the Maven extension, which covers pom.xml.

For the third one, we can partially do that because the context menu registration in VS Code is declarative. We can use clauses to achieve part of the goal but it won't be perfect. So when it's impossible to precisely determine whether we need to show an item, we tend to show it for visibility.

[ccarv]

I haven't had a chance to look at the Maven view but it's my understanding that it's a logistical view of the Maven POM file.

The right click context aware menu would satisfy Maven (or Gradle) goals such as "install, clean, compile, etc", and possibly the ability to refactor Java packages and classes, which is severely lacking in VSCode.

The Java Dependency Viewer is the plugin in VSCode nearest to closing this gap because it provides a sensible view of the package structure. From a tree node perspective, the only missing element is SCM operation indicators and being able to see Maven (or Gradle) specific project files, like POM.xml.

I am going to create some UI mockup screens to better demonstrate how valuable these changes can be to large Java projects.

[jdneo]

@ccarv Meanwhile, I would suggest to have a try with the Maven extension, which provides some features like executing Maven goals.

[Lucas3oo]

Is it possible to extend the tree view's context menu? Like adding git commands?
In that way people that want a clean view can have that and the ones like me that want to the the main view like in Eclipse/NetBeans/IntelliJ can have an additional plugin to get all the extra features.

[jdneo]

We have a way to do that, see: https://github.com/microsoft/vscode-java-dependency/wiki/Register-Command-onto-the-Nodes-of-Project-View