New project type for "generic" projects by mbien · Pull Request #9736 · apache/netbeans

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

A new project type which can be used to work with arbitrary directories on your system. It integrates with project groups and other features like a regular project.

The project is identified by a marker file or alternatively by a property stored in the NB config. User can modify this setting during project creation or afterwards using the properties window (marker file becomes settings storage once something is changed)
PR currently contains wizard, project properties window, basic actions and file filter settings
open required projects action (returns one level like the maven impl)
potentially a building block for more features (e.g DirectoryProjectProvider with GenericProject impl and DirectoryGroup replacement #9737)
rust modules were used as reference since they were well written and documented (thanks @vieiro !)
the repo was seeded with .nbgp markers for testing purposes

targets NB 33 but there is no hurry (other PRs like mvn 3.10 and jdk28 support have priority for the next release)

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

screenshots

Details

Open as Generic Project (active on all folders which aren't projects yet)

wizard

context menu

all clusters opened as generic project without the IDE exploding

matthiasblaesing · 2026-10-22T18:05:14Z

Something is broken here. There files with name .nbgp added all over the place. From a quick glance that file acts as marker and it should not be necessary to mark projects again as projects. For the naming, there is alreay .nbproject as a directory, just a thought though.

mbien · 2026-10-23T08:37:54Z

From a quick glance that file acts as marker and it should not be necessary to mark projects again as projects

those paths are no projects atm + the first commit was mostly meant for testing purposes (got inspired by #9624).

neilcsmith-net · 2026-10-23T08:55:42Z

Thanks for starting the initiative on this. It's definitely going in the right direction in my opinion. Need more time to review properly, but few initial comments.

As you know, I wanted to use the default AuxiliaryConfiguration attributes or file (.netbeans.xml) as marker. One reason was to not have two files in the case of configuration and sharing. I don't have concern with using a different marker, but I think any shared marker file should also contain any configuration. This would require a bespoke implementation of the configuration, or maybe just an AuxiliaryProperties implementation. This might mean the shared project marker should be something like nbproject.properties instead.
Settings like Display Name should be shared if the marker is shared. There should be a mechanism to migrate settings between file and attributes when converted.
The marker filename should also be brandable. Other platform applications using project support may want their own markers rather than creating NB branded ones, and it would stop applications picking up each others' projects.
I have some concerns about having any implementation of Delete. On the other hand, we almost certainly want the functionality to Forget.
The need to add more exceptions to FoDLayersProvider is a little concerning - not sure if there's a better way to mark these things though?

- 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

mbien · 2026-10-26T09:27:12Z

points 1-3 implemented:

as mentioned back when we chatted about this. I agreed in principle but said that this is tricky due to chicken-egg problems (e.g you can't store aux config for a project without a project). But I think I found a solution. Config impl is properties based, initial marker is an empty file which happens to be a valid properties file -> marker becomes dual purpose as config too.

I have some concerns about having any implementation of Delete (...) Forget

this actually uses the default impl. Dialog has a check box with "also delete project files" which is unchecked by default. So forget is default.

The need to add more exceptions to FoDLayersProvider is a little concerning - not sure if there's a better way to mark these things though?

i did some archeology to find the bugzilla numbers (put them in the code comments). It didn't seem to be a big concern back then. What would be good would be a test which actually fails in a way which makes sense for the dev. Failures for this were completely obscure and it was difficult to figure out why the checks were there in the first place. I don't have the full picture of this so I can't do much unfortunately.

added new-project context menu action but i just noticed that it doesn't infer the relative location of the selected node for the project wizard. So we might want to remove it again - kept it to play around with it.

will add screenshots

neilcsmith-net · 2026-10-26T10:16:14Z

points 1-3 implemented:

Thanks! Will take a deeper dive as soon as I can.

as mentioned back when we chatted about this. I agreed in principle but said that this is tricky due to chicken-egg problems (e.g you can't store aux config for a project without a project). But I think I found a solution. Config impl is properties based, initial marker is an empty file which happens to be a valid properties file -> marker becomes dual purpose as config too.

Yes, that was one solution I thought we'd discussed. The other is storing the initial request in a Set<FileObject> which might have the added benefit that no marker or attribute is created until after initial project load.

Still, what you have looks good, and for user editable configuration, a properties file probably beats the default XML. I know someone on dev@ mentioned YAML, but anything that doesn't need dependencies is a plus.

I have some concerns about having any implementation of Delete (...) Forget

this actually uses the default impl. Dialog has a check box with "also delete project files" which is unchecked by default. So forget is default.

Ah, yes, forgot the default behaviour. Our naming here sucks! 😄

will add screenshots

👍

jtulach

in #9650 I attempted to need no persistent changes on disk
if the general perception is that persistent changes are OK, then...
... I am not going to object

jtulach · 2026-10-26T11:27:17Z

+                new GpActionProvider(this),
+                new GpAuxiliaryProperties(this),
+                this
+        ), "Projects/" + PROJECT_KEY + "/Lookup"); // NOI18N


This is a "layer" API that shall be documented in arch.xml.

jtulach · 2026-10-26T11:30:46Z

+        if (markerFile) {
+            createMarker(dir);
+            if (isAttributeProject(dir)) {
+                dir.setAttribute(MARKER_ATTRIBUTE, null);


Marker is an API that shall be documented in arch.xml

when I was designing FileObject.get/setAttribute I was hoping it will be used exactly for these "marking" purposes

it has never flied...

... probably because we never integrated with underlying Ext4 or MacFS attributes...

probably because we never integrated with underlying Ext4 or MacFS attributes...

Funnily enough I think persistent changes are good for this as long as they are userdir specific by default. Having attributes that are stored outside of the userdir would actually change my perspective on whether this is the right approach. I would then prefer something like CPPLite that stores its projects in Preferences - https://github.com/apache/netbeans/blob/master/cpplite/cpplite.project/src/org/netbeans/modules/cpplite/project/CPPLiteProject.java

mbien · 2026-10-26T12:43:35Z

in Use fallback root project when folder project group has no owning project #9650 I attempted to need no persistent changes on disk

if the general perception is that persistent changes are OK, then...

... I am not going to object

Tbh i would see the in-memory approach as an optimization + if i see this correctly there probably isn't anything what would prevent improving this later if needed. But I think it probably isn't a big issue to store a property when a folder was "mounted" -> opted for simplicity.

- 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-26T21:54:15Z

file filter settings + open as generic project action. Since the review started lets call this PR feature complete, additional features would be added via followups unless something essential is still missing.

jtulach · 2026-10-27T07:26:10Z

+                    </test-dependency>
+                </test-type>
+            </test-dependencies>
+            <public-packages/>


less API is more ...

e.g. I am glad to see there are no public-packages in this generic.project module

on the other hand, there are the group="layer" and group="java.io.File" APIs

we should document them and expose them at javadoc area

however ant javadoc is likely to fail with any package/class being public

maybe exposing a single API package with for example MARKER_FILE value?

mbien added this to the NB33 milestone Oct 21, 2026

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

mbien mentioned this pull request Oct 21, 2026

DirectoryProjectProvider with GenericProject impl and DirectoryGroup replacement #9737

Draft

jtulach mentioned this pull request Oct 22, 2026

Use fallback root project when folder project group has no owning project #9650

Open

2 tasks done

mbien added 13 commits October 25, 2026 19:22

Seed NB repo with generic-project marker files

f81a904

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

initial gp impl

1711c98

project wizard

e2f7415

[action] open required projects

2632c1a

[action] rename action + some refactoring

e2c9547

general project properties

d476e3e

marker now optional

df8802b

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

2f402e4

refactored into packages

0f6ec0d

refactored base package

9ec3497

fix FoD tests

16c2ab0

register new-project action shadow

fc27d0c

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

mbien force-pushed the generic-project branch from 2ff1289 to cfe7c53 Compare October 26, 2026 09:27

jtulach reviewed Oct 26, 2026

View reviewed changes

mbien added 2 commits October 26, 2026 18:37

File filter properties

36a7171

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

Open as Generic Project action

a33d972

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

mbien marked this pull request as ready for review October 26, 2026 21:54

jtulach reviewed Oct 27, 2026

View reviewed changes

Navigation Menu

Repository navigation

New project type for "generic" projects - #9736

New project type for "generic" projects#9736
mbien wants to merge 15 commits into
apache:masterfrom
mbien:generic-project

mbien commented Oct 21, 2026 •

edited

Loading

Uh oh!

matthiasblaesing commented Oct 22, 2026

Uh oh!

mbien commented Oct 23, 2026

Uh oh!

neilcsmith-net commented Oct 23, 2026

Uh oh!

mbien commented Oct 26, 2026

Uh oh!

neilcsmith-net commented Oct 26, 2026

Uh oh!

jtulach left a comment

Uh oh!

Uh oh!

jtulach Oct 26, 2026

Uh oh!

jtulach Oct 26, 2026

Uh oh!

neilcsmith-net Oct 26, 2026

Uh oh!

mbien commented Oct 26, 2026

Uh oh!

mbien commented Oct 26, 2026

Uh oh!

jtulach Oct 27, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

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

Uh oh!

screenshots

Uh oh!

matthiasblaesing commented Oct 22, 2026

Uh oh!

mbien commented Oct 23, 2026

Uh oh!

neilcsmith-net commented Oct 23, 2026

Uh oh!

mbien commented Oct 26, 2026

Uh oh!

neilcsmith-net commented Oct 26, 2026

Uh oh!

jtulach left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jtulach Oct 26, 2026

Choose a reason for hiding this comment

Uh oh!

jtulach Oct 26, 2026

Choose a reason for hiding this comment

Uh oh!

neilcsmith-net Oct 26, 2026

Choose a reason for hiding this comment

Uh oh!

mbien commented Oct 26, 2026

Uh oh!

mbien commented Oct 26, 2026

Uh oh!

jtulach Oct 27, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

mbien commented Oct 21, 2026 •

edited

Loading