Hello I've made some progress into providing a SPI for MCP tools. I used Anton's dukehoff-mcp project to try it. If yo want to look at the changes and try it: https://github.com/ehsavoie/netbeans/tree/acp https://github.com/ehsavoie/dukehoff-mcp/tree/acp
I tested that with copilot in STDIO. I saw that copilot also supports being a server so I'll try that soon. Also I did only some basic rendering buit as you can see it is quite basic so if someone with a better UX experience than myself can take a look at that I would also appreciate. Cheers, Emmanuel ---------- Emmanuel Hugonnet http://www.ehsavoie.com http://twitter.com/ehsavoie Le ven. 16 oct. 2026 à 13:03, Michael Bien <[email protected]> a écrit : > On 10/15/26 11:29, Michael Bien wrote: > > 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) > > short note since I was reading through the code of bean bot: > > if you ask it to list all tabs and some opened files are outside of the > project of the session -> it won't see those (other actions work > similarly). > > Basically exactly what we talked about. If any folder could be a project > it would likely continue to work without any adjustments to new > concepts. It would see a project which happens to have more projects in it. > > not to mention: you could have two agent sessions working on two folders > at the same time without knowing from each other. Both could be opened > in the same project group. With the workspace proposals this would be > hard to do since they were essentially a side grade of a pg. (nb can > open one at a time) > > (it does still see absolute paths but that would be difficult to hide > from NB's POV since there are simply too many FileObjects, Files, Paths, > Strings etc everywhere. It could also ask tooling e.g maven) > > -mbien > > > > > > 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]>>: > >> > >> > >> 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 > > > --------------------------------------------------------------------- > 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 > > > >
