Hi Michael, Path-based is how we see it too. Our standalone server works exactly that way: it is started on a base folder, finds the projects below it, and names everything relative to it. So, a "folder project" as the root of a group would fit us well, and so would Jarda's workspace API. What matters to us is less the mechanism than three things it should offer:
1. Finding the projects for a folder. Given the folder a session works in, NetBeans should tell us which projects belong to it and where their Java sources are. That includes projects that are not at the top: often a repository's build sits in a subfolder, or the folder holds several checkouts side by side. 2. One "ready" signal: projects open, class paths registered, indexing done. 3. A boundary for writes. Your point about harness rules applies to our refactorings too: they write files themselves, outside the harness's view. We are adding a limit so that a refactoring only changes files under the session's base path (inside the IDE, the open projects) and is refused otherwise. If NetBeans knew that base path as a first-class thing, every IDE tool could check it the same way. This would be a small API change in the IDE that plugins like ours, or an ACP plugin, could build on. Toni Am 15.10.26, 11:30 schrieb "Michael Bien" <[email protected] <mailto:[email protected]>>: I am still in the pro-project camp since it seems to be the easiest solution while being well supported :) LLM harness permissions are path based and map well to projects or repos. (in a nutshell: you start a session and that is your base path by default, everything outside it is external and requires extra permissions, as you said everything is named using relative paths since that is all the session knows) It could be a new project type with the primary job of representing a path. It could be the root of a pg, or anywhere else. I suppose it would be pretty easy to add a method which returns all pgs which have a project at their root? the "Folder of Projects" pg option could be adjusted accordingly to create a .. project folder ;) in a regular group and this would also allow to add base folders to existing pgs (at root or anywhere else). -mbien On 10/15/26 09:50, Anton Epple wrote: > Hi Jaroslav, > > Thanks for the offer, I'll take you up on it ��. From our perspective a > "Workspace API" would be grand! Here are concrete use cases from our MCP > server. Each one is something we had to build ourselves, around OpenProjects: > > 1. Workspace folders and paths. Agents name files relative to "the > workspace". We need its root folders to resolve and display paths. Inside the > IDE there is no such notion, so we fall back to absolute paths. > 2. Opening a folder. Given a folder, find its projects: the folder itself, > its contained projects, or projects a few levels down (a repository whose > build sits in a subfolder). We wrote that search ourselves. > 3. One readiness signal. "Projects open, class paths registered, indexing > done." Large Maven workspaces register class paths in stages. On GlassFish, a > usage search right after the first scan found 60 of 73 files. We now wait > until indexing has been quiet for 5s and re-read the source roots. > 4. More than one workspace per IDE. In nbcode, every LSP client has its own > projects, served through Lookups.executeWith. An agent connecting to the IDE > needs the same: its own workspace, not the global OpenProjects. > 5. Workspace trust. Gradle projects are only loaded after a trust question, > which nobody can answer headless. We set the global execution rule in our own > userdir. A per-workspace trust (like VS Code's) would fit agents much better. > 6. External edits. Agents write files directly. Before answering, we refresh > the workspace folders. A workspace-level "refresh and wait until the index > caught up" would replace that. > > 3 and 4 are the ones that would help most. > > Thanks, > Toni > > Am 15.10.26, 08:46 schrieb "Jaroslav Tulach" <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>>: > > > Hello guys, > I am glad you decided to help NetBeans catch the AI train! > > >> The one real piece of work is on my side: our tools currently open a >> workspace folder themselves. Inside the IDE they should use the projects >> that are already open. I'll adapt that, and then open a PR on your branch >> with the provider, as you suggested. > > There is a discussion [raging > nearby](https://lists.apache.org/thread.html/jx5ox9pjltzo2r16gqljo7zqvysywhql > <https://lists.apache.org/thread.html/jx5ox9pjltzo2r16gqljo7zqvysywhql> > <https://lists.apache.org/thread.html/jx5ox9pjltzo2r16gqljo7zqvysywhql> > <https://lists.apache.org/thread.html/jx5ox9pjltzo2r16gqljo7zqvysywhql>>) > where I claim NetBeans should adopt a concept of a workspace (e.g. > project group) more. Support for tools like MCP, LSP, etc. is exactly > the reason why having a "pg" as a 1st class citizen would help such > tools to integrate with NetBeans. > > > There already is > https://bits.netbeans.org/dev/javadoc/org-netbeans-modules-projectuiapi-base/org/netbeans/api/project/ui/OpenProjects.html#getActiveProjectGroup > > <https://bits.netbeans.org/dev/javadoc/org-netbeans-modules-projectuiapi-base/org/netbeans/api/project/ui/OpenProjects.html#getActiveProjectGroup> > > <https://bits.netbeans.org/dev/javadoc/org-netbeans-modules-projectuiapi-base/org/netbeans/api/project/ui/OpenProjects.html#getActiveProjectGroup> > > <https://bits.netbeans.org/dev/javadoc/org-netbeans-modules-projectuiapi-base/org/netbeans/api/project/ui/OpenProjects.html#getActiveProjectGroup>>() > I believe we should extend that class to provide some concepts of > https://code.visualstudio.com/api/references/vscode-api#workspace > <https://code.visualstudio.com/api/references/vscode-api#workspace> > <https://code.visualstudio.com/api/references/vscode-api#workspace> > <https://code.visualstudio.com/api/references/vscode-api#workspace>> - I > am looking for real use-cases to justify such changes. > > > If there is anything to add there to make your train catching easier, > please spell it! > -jt > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > For additional commands, e-mail: [email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> > > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > <https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists> > <https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists> > <https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists>> > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]> > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > <https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] <mailto:[email protected]> For additional commands, e-mail: [email protected] <mailto:[email protected]> For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists <https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
