Nesting Projects by their Cluster

[jtulach]

• now, when Show nested projects co-located and indented #9602 gives us a way to co-locate projects
• shalln't we use it for NetBeans projects as well
  • alas, right now there is no "nesting hierarchy" of NetBeans projects
  • they are organized into clusters, but clusters them selves aren't projects
• this PR tries to fix it by creating (sample projects) for platform, ide, java cluster
• with such changes, we get "one layer nesting"
  • clusters own their modules and are indented as outline below

• each "cluster project" lists all its modules
• e.g. one can right click and easily open some or all modules from a cluster

[jtulach]

This list of subprojects has been generated by following shell command:

for i in *; do ls $i/nbproject/project.xml >/dev/null 2>/dev/null && echo "<project>$i</project>"; done | sort

Using such a script requires manual and tedious work. Ideally the final solution would not rely on shell script at all.

Alternative A: Ant Task

• Have an Ant task in nbbuild/antsrc sources to generate all the "cluster project"
• run it as part of CI to verify the structure is up to date
• Pros: reusing existing (althrough outdated) freeform project
• Pros: easier manual customization with existing UI

Alternative B: New project type in apisupport

• We could also recognize the "cluster directories" as projects without generating anything on disk
• To do that the apisupport project would provide new project type
• Pros: no freeform project files on disk
• Pros: always up to date with list of clusters and modules

Opinions?

[neilcsmith-net]

I would use nbbuild/cluster.properties not the disk structure. It might highlight inconsistencies. Freeform projects might not be a bad thing as could be useful for other things in future.

[mbien]

a variant of A) could commit the project files but add a tripwire test checking if they still make sense?

Using the build to generate them would break your project group if opened before NB was built.

We have several tripwire tests already which trigger when someone forgets to update something while working on unrelated tasks. (e.g the most recent one checking if an editor hint knows about all javac error keys)

build system job is always enabled, might be a good place for it (

netbeans/.github/workflows/main.yml

Line 385 in 1336aa1

build-system-test:

).

I would use nbbuild/cluster.properties not the disk structure.

since this isn't used by the build at all (project node doesn't even have a build action - which is OK i think) and purely for dev-time convenience I think it is ok/better to add everything which is currently in the folder. Who knows what cluster config the dev is working on atm + you don't have to open everything anyway.

(comment in the file would also help mentioning that this isn't used by the build, only for dev-time convenience)

[neilcsmith-net]

Who knows what cluster config the dev is working on atm

?? Not sure why that's relevant? The cluster file includes nb.cluster.ide.dir and nb.cluster.ide which already tells you the root folder of this cluster and all the projects that should be listed below. Ideally there is a single source of truth for this stuff.

[mbien]

If the cluster subdivision already maps the folder structure -> awesome. I wasn't sure if everything what has a project is actually in the cluster config. The unit test could simply load the property file and compare it against the project.xmls. But tbh the folder is the source of truth, cluster config is "just" release config and probably doesn't have to show everything what is in the repo.

[neilcsmith-net]

No, this case is exactly the same - take any clusters that share a dir and merge the projects. If it didn't work like that the build wouldn't work correctly.

@jtulach of course, the other way around would be to generate the cluster config from the new folder project files. Any way that doesn't involve keeping everything in sync manually! 😄

[mbien]

I feel we are talking about two different things. This nesting here is to visually group projects. The grouping however is by path. The proposed nesting projects are just a trick to have something open which is parent node to NB modules. You could argue that they are redundant if #9631 makes it in - since it would simulate the same behavior if you open the "cluster dir".

This has nothing to do with the build. The nesting projects are not used for the build. NB project list will nest the project if: it is in the same dir && a parent node is open on a parent path (may or may not be a "nesting project").

That is why I said whatever this ends up being it should be documented in a comment what the project files are used for.

I would probably recommend to not merge it and explore #9631 first - maybe this is going to be good enough.

[neilcsmith-net]

I'm fully aware of those things - the correlations between build clusters and paths on disk exists for a reason.

I disagree that #9631 replaces this.

[mbien]

I disagree that #9631 replaces this.

Lets make sure to document the subtle differences between this PR and #9631 which looks like:

(I suppose the icon would be different)

[neilcsmith-net]

@mbien given my current lack of access to a time machine, the point stood at the time it was made! 😜

Even now I'm not sure if it offers cross-cluster view options or the potential to be updated to validate the build configuration. Still, this is the problem with discussing across multiple things in flux.

[neilcsmith-net]

Looks useful. Please address the optionality aspect of #9624 first though or this all gets complicated to unwind!

The cluster hierarchy should probably reflect the contents of nbbuild/cluster.properties? That should contain all the required information to generate this? It might also offer the ability to highlight projects that are missing from the cluster list, which sometimes causes contributors some confusion.

Having the clusters be freeform projects might be useful to extend to cluster wide tasks in future.

Please ensure there's at least one label on any PR when it's opened or the CI will fail.