Hi, I agree with the split :) Three questions: 1. Which NetBeans release are you aiming for, and does the acp.* code stay in the extra cluster for now? I didn't think about tha 2. Can we use a published build of your branch to compile against (a snapshot, or the CI dev build), or should I build it locally? 3. Are you OK with dropping JavaRefactoringToolProvider once ours is in, or would you rather keep it as a fallback? Yes :) ---------- Emmanuel Hugonnet http://www.ehsavoie.com http://twitter.com/ehsavoie
Le mer. 14 oct. 2026 à 17:56, Anton Epple <[email protected]> a écrit : > Hi Emmanuel, > > thanks, and great that you're pushing this. NetBeans really shouldn't be > left standing at the station. > > I've looked at your branch. The good news: your McpToolProvider fits our > tools almost one-to-one. Our tools already have a name, a description and a > JSON schema, and they return text plus an error flag, which is exactly what > your server turns into content and isError. So plugging them in is mostly a > thin adapter. > > Here's what I'd propose as a split: > > - You: ACP, the chat window, the MCP server, and the IDE-specific tools > (editor, Git, projects). Those are things only a running IDE can offer, and > they fit your design well. > - Us: the Java tools. find_usages/find_implementations, outline (now also > for types of the JDK and dependencies, which agents otherwise guess), > compile errors without a build, and the refactorings (rename, > change_signature, move, safe_delete, inline) with a compile check after > each one. Your JavaRefactoringToolProvider would then become redundant. > Your generic rename/find_usages/safe_delete currently share names with > ours, so we should sort out the names, e.g. yours stay for files and > non-Java content. > > 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. > > In the longer run, I'm happy to contribute the Java tools to NetBeans > itself as a module, so users get them without an extra plugin. Since the > code was written outside the ASF, we'd go through the usual grant and IP > clearance for that; If we chose to go this route and the project is willing > to accept a donation, I'll take care of it on our side. Otherwise it can > stay separate - the beauty of a modular system. > > Three questions: > 1. Which NetBeans release are you aiming for, and does the acp.* code stay > in the extra cluster for now? > 2. Can we use a published build of your branch to compile against (a > snapshot, or the CI dev build), or should I build it locally? > 3. Are you OK with dropping JavaRefactoringToolProvider once ours is in, > or would you rather keep it as a fallback? > > Cheers, > Toni > > Am 14.10.26, 16:58 schrieb "ehsavoie" <[email protected] > <mailto:[email protected]>>: > > > Hi Anton, > That's very nice to read :) > I was just trying to do some basic stuff and didn't put much thinking into > those tools as I started everything as a PoC. > I just wanted to ensure that NetBeans users didn't feel left on the side > while the AI train was passing ;-) > Also after meeting Geertjan last week I felt like I had to give back mre to > the only IDE you need :-) > It would be great to find a way to use your MCP tools which are far more > advanced than mine as i just wanted to test if the agent would be able to > access them :) > I would be happy to discuss that further, feel free to open PRs on my > branch > Cheers, > ---------- > Emmanuel Hugonnet > http://www.ehsavoie.com <http://www.ehsavoie.com> > http://twitter.com/ehsavoie <http://twitter.com/ehsavoie> > > > > > Le mer. 14 oct. 2026 à 16:18, Anton Epple <[email protected] <mailto: > [email protected]>> a écrit : > > > > Hi Emmanuel, > > > > great to see this. I've been working on something closely related, from > > the other direction: Dukehoff MCP for Java runs a headless NetBeans as an > > MCP server for agents outside the IDE, such as Copilot CLI, Claude Code > and > > Codex. In VS Code it runs inside the Apache NetBeans extension: Our > > extension just ships a cluster in its nbcode/ folder, which the Apache > > extension loads. It's Apache 2.0: > > > > - https://github.com/dukehoff-gmbh/dukehoff-mcp < > https://github.com/dukehoff-gmbh/dukehoff-mcp> > > - > > > https://marketplace.visualstudio.com/items?itemName=dukehoff.dukehoff-mcp-java > < > https://marketplace.visualstudio.com/items?itemName=dukehoff.dukehoff-mcp-java > > > > > > Our tool sets overlap: rename, find usages, safe delete, move and inline > > are on both sides. Since we built an evaluation harness early on (real > > agent sessions, with and without the tools), a few findings might be > useful > > for your PR: > > > > 1. Address symbols by name, not by file and offset. Our tools take > > com.acme.Foo#bar(String). Agents know names; offsets cost them an extra > > read, go stale after the agent's next edit, and an overload needs its > > signature anyway. > > 2. Check compilation after every refactoring. Each refactoring reports > the > > compile errors it introduced, including in files it didn't touch, such as > > callers of a method that became private. Then the agent doesn't need a > > build to find out. > > 3. The server instructions decide whether agents use the tools at all. > > Without instructions that map questions like "who calls X" to > find_usages, > > agents kept grepping. With them, in our tests a rename across NetBeans' > own > > java/ folder took 5 agent turns instead of 48. > > 4. Don't answer while the index is still being checked. We tried it, and > > the results were silently incomplete. Agents can't tell; they need a "not > > ready yet, call again". > > > > Beyond that, we have change_signature, compile errors without a build, > > structural search and replace with Jackpot rules, and a one-call debugger > > stop in a test. > > > > It would be a pity to end up with two implementations of the same Java > > tools in the NetBeans world. I'd be happy to align on this, either by > > making our tools available through your McpToolProvider SPI, or by > talking > > about bringing the Java tools into NetBeans itself. Happy to discuss here > > or on a call. > > > > Best regards, > > Toni > > > > Am 14.10.26, 15:52 schrieb "ehsavoie" <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected] > >>>: > > > > > > Hello, > > I've been playing around to use Agent Client Protocol to connect a coding > > agent into NetBeans. > > I'm trying to expose NetBeans internal features to the agent for > > refactoring or searching code. > > It is a work in progress, but part of it is already on a PR [1]. > > I've tested in with Github Copilot and IBM Bob so far and I find it nice > > for now even if it is a bit rought on the edges. > > Cheers > > Emmanuel Hugonnet > > http://www.ehsavoie.com <http://www.ehsavoie.com> < > http://www.ehsavoie.com> <http://www.ehsavoie.com>> > > http://twitter.com/ehsavoie <http://twitter.com/ehsavoie> < > http://twitter.com/ehsavoie> <http://twitter.com/ehsavoie>> > > > > > > > > > > > > > > > > > > [1]: https://github.com/apache/netbeans/pull/9712 < > https://github.com/apache/netbeans/pull/9712> < > > https://github.com/apache/netbeans/pull/9712> < > https://github.com/apache/netbeans/pull/9712>> > > > > > > > > > > > > --------------------------------------------------------------------- > > 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 > > > >
