As for the module being in the extra cluster, i put it there because this is experimental but we can move it if you think it makes more sense somewhere else and if others agree with that. Cheers, --------
Le mer. 14 oct. 2026 à 18:22, ehsavoie <[email protected]> a écrit : > ehsavoie > 18:19 (il y a 0 minute) > > > 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 that but I think we are in feature freeze so I guess > it would be 33. > > 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? > I'll update my branch soon with my latest changes, I can push a build on > dropbox to share. > CI runs won't be available until the release I think. > > 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 >> >> >> >>
