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]>>: 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>) 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>() 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> - 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]> 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
