LogicalViewProvider.WithNestedProjects allows one to logically nest projects

[jtulach]

The goal of this PR is to design an API that would allow projects to nest children projects. Such nesting shall help us solve a long time pending issue that Mark @struberg pointed out a decade ago. E.g. that for example rich Maven projects aren't represented hierarchically.

The change is only visual. The projects are still open - e.g. goto type, symbol or file will continue to work as expected.

The change to Maven project isn't part of this PR, but I'll test the API on Maven to see if it can deliver and really simplify organization of huge projects.

[mbien]

I like it as UI option and indeed many asked for something like that before. However, I believe that the tree will become deep quickly (esp in larger projects) which will make me want to have the flat structure again (+ project groups for context switching).

The sub-project tree must also retain a way to distinguish between closed and opened project. (which might be tricky to visualize, since "Maven 4 API" is a project and "Maven 4 API :: Meta annotations" is a project too - see screenshot where both are closed)

The top level project looks like this right now for comparison:

Unless the user hits open required projects -> open all projects - which can be overwhelming - it remains usually fairly easy to navigate.

[mbien]

although we could probably mitigate many horizontal-scroll issues of deep trees by tweaking the node indentation.

[neilcsmith-net]

I like it as UI option and indeed many asked for something like that before. However, I believe that the tree will become deep quickly (esp in larger projects) which will make me want to have the flat structure again (+ project groups for context switching).
...
Unless the user hits open required projects -> open all projects - which can be overwhelming - it remains usually fairly easy to navigate.

Agreed! This looks like a great option, as long as it's optional and off by default (for now at least). It reminds me a little of the package view tree options - sometimes useful, often unwieldy - flatter is often easier to use in practice.

The sub-project tree must also retain a way to distinguish between closed and opened project.

My first thought was whether leaf or not. However that might conflict with representing nested project hierarchies. The second thought was, why? With the UI like this, what does closed vs opened mean? Maybe projects just open on-demand as needed? Which is not that different to double-clicking on them now.

The varargs changes in Children might be a problem.

[mbien]

I don't want to derail this but something we could try is to add more sorting options to the project list. Topological sort would have the parent above the child. So you would have the root project on top displaying the sub module tree (see screenshot), and all other projects you open would show up below. Even manual re-ordering mode would help I think.

[JaroslavTulach]

... sorting options to the project list. Topological sort would have the parent above the child....

Better sorting is a great idea! It doesn't require any API changes. It is not really achieving all, I'd like to, but it is a good non-disturbing start. I'll try it.

[JaroslavTulach]

Unless the user hits open required projects -> open all projects

When dealing with unknown source (like Apache Maven or OpenJDK is to me), the whole point is that one must open all projects. Otherwise goto type, file, find usages & co. work poorly.

Being for Experts

NetBeans has a unique concept of handling projects. It is a completely different workflow than other IDEs are built around. I like it because it is flexible. However it also complicates things - because it is flexible. Projects are stored in Git repositories these days. When opening such a project, it (almost all the time) makes sense to open all the projects in the Git repository. That's not a NetBeans philosophy. NetBeans allows one to cherry pick and open only some of the projects.

Being Different

Such a flexibility makes NetBeans an IDE for experts. However it also comes with a cost. Not only implementation wise (IDE has to be ready for set of projects being "half open"), but also from a UX perspective.

Maybe projects just open on-demand as needed?

Every "expert" has different set of subprojects open and then the behavior of the IDE is different. Such a "magical flexibility" makes the UX poor.

Other IDEs have a concept of workspace. When opening Apache Maven sources in a "workplace", then the IDEs just open all the nested projects in the Apache Maven Git repository.

Simplify UI. Keep Flexibility.

I believe the time has come to straighten the NetBeans IDE position by adjusting to common UX while keeping the flexibility under neath. NetBeans already has a support for groups of projects. Just the UX feels old fashioned and like a second class citizen. I'd like to improve the UX by using the same infrastructure to mimic the concept of a "workspace". Ideally I'd like to rework the File menu to offer Open/Close Folder, Add to Workspace, Save Workspace as just like VSCode File menu provides.

TL;DR

Experts "in the know" can still Open Project... one by one and work only with a properly curated and selected subset. However for clueless users working on an unfamiliar code base, I believe we have to lead the UX towards open all the projects at once.

This is just an outline of my plan. It is out of scope of this PR.

[matthiasblaesing]

When dealing with unknown source (like Apache Maven or OpenJDK is to me), the whole point is that one must open all projects. Otherwise goto type, file & co. work poorly.

Be careful! If you say that opening a project opens alls submodules I veto this unless you can explain how you intent to handle this: https://github.com/openhab/openhab-addons/tree/main/bundles. These are > 500 submodules. The IDE currently struggles in the project open dialog, I don't want to know how it will feel when all 500 submodules are opened.

[JaroslavTulach]

Be careful! If you say that opening a project opens alls submodules ... These are > 500 submodules. The IDE currently struggles in the project open dialog, I don't want to know how it will feel when all 500 submodules are opened.

NetBeans own codebase is another example where opening all projects takes the IDE to its limits. As such, I have no intention to change the workflow for expert users. Rather I'd offer an alternative actions that would mimic what Apache NetBeans VSCode Extension already does.

I am a huge believer in synergy. The Apache NetBeans VSCode Extension is a base for Java Platform Extension with a 6M of downloads. That makes it an important asset for its publisher. It should be in the interest of the publisher as well as Apache NetBeans project to make sure both the extensions work well even on projects like openhub-addons.

Hence, by aligning the UX, we shall mutually straighten our forces to (possibly) improve the IDE's strength in handling those 500+ modules without current scalability issues. Of course, this is just a speculation - it may not happen - however without the common UX ground it certainly won't happen. We have to set the environment up for synergy first, and then believe the synergy inevitably emerges. That's why I plan to offer those workspace UX actions.