DirectoryProjectProvider with GenericProject impl and DirectoryGroup replacement by mbien · Pull Request #9737 · apache/netbeans

mbien · 2026-10-21T02:46:59Z

Refactors the directory-based project group action to use the new generic project type as base, combined with the pre-existing SubprojectsGroup. (see #9738 for generated design doc)

new API in lookup:

DirectoryProjectProvider SPI added with GpDirectoryProjectProvider as reference impl
Single method interface defines a single createProject(FileObject dir) method and is located in ide/projectuiapi
ProjectManager has now a new API method findOrCreateDirProject()

-> Relationship is now reversed. Functionality moved into the Lookup instead of hardcoded logic within a specialized Group impl. (could be potentially swapped out if needed)

Migration path was added to restore groups (old user config) of kind directory as generic project based SubprojectsGroup.

UI difference:

directory groups will now have their generic project displayed as node. We could probably find a way to hide it if needed.

this builds on top of #9736 and contains the commits so that it can be tested together. Commits marked with [2] belong to this PR.

Assisted-by: qwen3.8-27b + granite4.2:8b

neilcsmith-net · 2026-10-23T09:10:17Z

Thanks. Generally going in the right direction in my opinion. Initial comments after quick glance through -

DirectoryProjectProvider should probably be an SPI in projectapi in https://github.com/apache/netbeans/tree/master/ide/projectapi/src/org/netbeans/spi/project The docs should be more general, and not special case groups - there are other potential use cases (at least one in the fallback PR).
The SPI method might be better named something like findOrCreateProject to convey what it does? On the other hand, depends what the API side does ....
General usage of the SPI should be via the project API, possibly ProjectManager::findOrCreateProject adjacent to ProjectManager::findProject ? Groups should use this via the API.
The API should use lookup all, first wins, to support 0, 1 or multiple DirectoryProjectProvider implementations.
Directory groups should probably not fail if no provider is available - one hiding mechanism is disabling / excluding the generic project module. The feature should not break if that is done.

- each cluster becomes a generic project so that it can be opened - .github receives one too

- the same file is used for both: marker and config storage - initial marker is an empty properties file (which is valid) - mode switch from marker to private moves properties on access - file name is brandable note: NB's auxiliary config storage has a 5s IO flush delay

- global file filters are enabled by default - optional per-project filter added - both configurable via project properties

inverse of the open project action, this action can convert any non-project to a generic project

mbien · 2026-10-29T15:31:16Z

changes:

rebase
API in ProjectManager.findOrCreateDirProject() - still thinking how to make the method less powerful since it does too much atm -> might not be its final form
refactored everything to use that API, moved the open-folder-as-project action to its destination (next to its inverse action open-project-of-folder; we have also the option to merge both)
regenerated Directory groups → Generic Project ("dirproject") #9738

i think that would be the first 4 points of #9737 (comment). Forgot about 5, next sync maybe.

remember that only the commits marked with [2] are for this PR since it contains another pr. Githup lets you select commits with the all-commits button in the files-changed tab.

neilcsmith-net · 2026-10-29T16:06:42Z

Thanks for taking on board the comments. This is looking exciting! Will take a deeper dive into the code and test some things as soon as I can.

API in ProjectManager.findOrCreateDirProject() - still thinking how to make the method less powerful since it does too much atm -> might not be its final form

I'm still trying to understand your concern here (following on from conversation elsewhere). My initial view looking at the updated code, in particular the action, is that is might actually handle one more thing - clearing the non-project cache when required. That feels like an implementation detail that a consumer of this method shouldn't need to consider. If it's actually needed?!

mbien · 2026-10-29T17:25:20Z

+        Project existing = findProject(projectDirectory);
+        if (existing != null) {
+            return existing;
+        }
+        for (DirectoryProjectProvider provider : Lookup.getDefault().lookupAll(DirectoryProjectProvider.class)) {
+            Project project = provider.createProject(projectDirectory);
+            if (project != null) {
+                return project;
+            }
+        }
+        return null;


assuming we keep this this way: we could probably move this whole section into a default method in impl which is a constant of type ProjectManagerImplementaiton (yes its an interface despite its name)

since there can be never enough abstraction layers between the client and the impl. This would be layer 3 I believe.

mbien added Editor ci:all-tests [ci] enable all tests ci:dev-build [ci] produce a dev-build zip artifact (7 days expiration, see link on workflow summary page) labels Oct 21, 2026

This was referenced Oct 21, 2026

New project type for "generic" projects #9736

Open

Directory groups → Generic Project ("dirproject") #9738

Open

mbien added 19 commits October 29, 2026 12:08

Seed NB repo with generic-project marker files

890827c

- each cluster becomes a generic project so that it can be opened - .github receives one too

initial gp impl

0e53368

project wizard

1b86c74

[action] open required projects

dc46121

[action] rename action + some refactoring

5f9e58f

general project properties

83fc01d

marker now optional

bc26589

[action] common default actions + copy, move, delete + rename

76344c3

refactored into packages

88b111c

refactored base package

cf2902e

fix FoD tests

ec25067

register new-project action shadow

82d5415

File filter properties

868e15d

- global file filters are enabled by default - optional per-project filter added - both configurable via project properties

Open as Generic Project action

16d5318

inverse of the open project action, this action can convert any non-project to a generic project

fix non-shared, external properties storage

5e64c61

added arch.xml

439b8cb

[2] dir project

815323a

[2] implement migration path on load

5269464

mbien removed the ci:all-tests [ci] enable all tests label Oct 29, 2026

[2] Create API and use it in open-as-project, dir-group etc

f545faf

mbien force-pushed the dir-project-group branch from 5fb379f to f545faf Compare October 29, 2026 15:11

mbien commented Oct 29, 2026

View reviewed changes

Navigation Menu

Repository navigation

DirectoryProjectProvider with GenericProject impl and DirectoryGroup replacement - #9737

DirectoryProjectProvider with GenericProject impl and DirectoryGroup replacement#9737
mbien wants to merge 20 commits into
apache:masterfrom
mbien:dir-project-group

mbien commented Oct 21, 2026 •

edited

Loading

Uh oh!

neilcsmith-net commented Oct 23, 2026 •

edited

Loading

Uh oh!

mbien commented Oct 29, 2026 •

edited

Loading

Uh oh!

neilcsmith-net commented Oct 29, 2026 •

edited

Loading

Uh oh!

mbien Oct 29, 2026 •

edited

Loading

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

mbien commented Oct 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

neilcsmith-net commented Oct 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mbien commented Oct 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

neilcsmith-net commented Oct 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mbien Oct 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

mbien commented Oct 21, 2026 •

edited

Loading

neilcsmith-net commented Oct 23, 2026 •

edited

Loading

mbien commented Oct 29, 2026 •

edited

Loading

neilcsmith-net commented Oct 29, 2026 •

edited

Loading

mbien Oct 29, 2026 •

edited

Loading