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.

[mbien]

essentially: we could name the project ide or IDE Cluster, dependent on what it should represent (folder or the cluster config). Either strategy is ok with me.

quickly checked and /platform has 116 projects right now, while nb.cluster.platform has 107 items.

        Properties props = new Properties();
        props.load(new FileInputStream("netbeans/nbbuild/cluster.properties"));
        System.out.println("conf "+ props.getProperty("nb.cluster.platform").split(",").length);
        System.out.println("actual "+Files.list(Path.of("netbeans/platform/"))
                .filter(Files::isDirectory)
                .filter(p -> Files.exists(p.resolve("nbproject/project.xml")))
                .count());

[neilcsmith-net]

It should map as per #536 and I disagree - the cluster config is the source of truth - miss something and it doesn't build correctly. We did not have cluster folders at donation.

[mbien]

the cluster config is the source of truth

source of truth for the build. The folders (ide, platform) may contain more projects apparently + the proposed nesting-projects here are not used for the build. But as I indicated before I actually don't care that much what we pick as long we document in a comment what those projects actually represent: all projects in that folder or an actual cluster.

[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.