You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by ehsavoie <em...@gmail.com> on 2026/10/14 13:52:25 UTC
ACP integration
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://twitter.com/ehsavoie
[1]: https://github.com/apache/netbeans/pull/9712
Re: ACP integration
Posted by ehsavoie <em...@gmail.com>.
Hello,
The idea was to avoid leaving the IDEand going to the console when you use
a coding agent so thatyou could use the existing IDE tools instead of just
relying on the agent.
Another reason was to cover also what Anton is doing: use the IDe internals
to reduce token consumption (liki the fact that the code is already
indexed).
I found nb-complete after sending the PR and I have to take a look at it. I
also would like to ensure this works with a sandboxed harness.
OpenCode is ACP compatible so this should work in the plugin :)
Cheers
Emmanuel
Le jeu. 15 oct. 2026 à 00:42, Michael Bien <mb...@gmail.com> a écrit :
> Hi Emmanuel,
>
> I think it would definitely be useful to make the running IDE instance
> available as a tool for LLM harnesses to interact with.
>
> I have been using OpenCode recently (but also other harnesses before)
> while using the IDE as window into the projects. Some models were
> running locally in a box with old gaming GPUs (via ollama atm), others
> use the typical providers. (there might be also news from the ASF soon
> for committers - not sure how much of it is public)
>
> But there are certainly some friction points with this workflow.
> Although I think the common case is to let the harness run everything in
> the background, there are certainly some convenience actions like "once
> finished, run 'clean verify' using the IDE instance again" or "once
> finished, open the diff using the IDE" or "use the default JDK
> configured for this project by asking the IDE instance". Potentially
> also via the notification system. Opening files via NB launcher works
> already pretty well since they land in the active instance.
>
> Using refactoring capabilities of tooling is also more efficient and can
> reduce a step of arbitrary length to seconds - dependant on the model
> and the refactoring, codebase size etc. Although this likely is better
> to be done by a headless service. Since the IDE instance is mostly there
> to interact with humans - while not needed as tool for the task itself.
> For example: I am not sure how useful it would be if the LLM would
> decide to open a refactoring window for the dev after 10 minutes of
> iterating on something before continuing with the next 10 minute step.
> (btw LLMs do a decent job generating NB's jackpot scripts which can be
> piped into refactoring tasks - since those are basically java syntax
> with extra sauce)
>
> e.g i told locally running granite4.2_8b via OpenCode to run a build on
> a pre existing "hello world" maven project before writing this reply and
> it is still contemplating how to reduce the compiler.release property
> since JDK 27 isn't in the env. But it looks like its nearly there -
> while the GPU fan is screaming from the other room. (-> would have been
> faster to ask the IDE where the JDK for this project is ;))
>
> It is easy to forget how much compute it actually requires to change a
> few chars compared to running a tool. (I can only encourage everyone to
> *try* to run a local model for a trivial task on a rainy day)
>
> Although security wise this can be really quick in "jesus take the
> wheel" mode. Letting LLMs run maven builds without locking the pom for
> edits is already more than sufficient to cause trouble. Even though this
> is the case with or without IDE, if it can use the IDE as tool to edit
> the pom it effectively circumvented a harness rule.
>
> btw there are some community plugins available which let you connect to
> LLM harnesses and render output in a NB window e.g I found BeanBot at
> https://github.com/anandb/nb-complete working pretty well. Although I
> have to admit i use the shell (running the harness UI for OpenCode or
> others) most of the time.
>
>
> (I will be mostly helping to stabilize the NB 32 release the next days
> so i might not have much time to think about new features)
>
> best regards,
>
> michael
>
>
> On 10/14/26 15:52, ehsavoie wrote:
> > 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://twitter.com/ehsavoie
> >
> >
> >
> >
> > [1]: https://github.com/apache/netbeans/pull/9712
>
>
Re: ACP integration
Posted by Michael Bien <mb...@gmail.com>.
Hi Emmanuel,
I think it would definitely be useful to make the running IDE instance
available as a tool for LLM harnesses to interact with.
I have been using OpenCode recently (but also other harnesses before)
while using the IDE as window into the projects. Some models were
running locally in a box with old gaming GPUs (via ollama atm), others
use the typical providers. (there might be also news from the ASF soon
for committers - not sure how much of it is public)
But there are certainly some friction points with this workflow.
Although I think the common case is to let the harness run everything in
the background, there are certainly some convenience actions like "once
finished, run 'clean verify' using the IDE instance again" or "once
finished, open the diff using the IDE" or "use the default JDK
configured for this project by asking the IDE instance". Potentially
also via the notification system. Opening files via NB launcher works
already pretty well since they land in the active instance.
Using refactoring capabilities of tooling is also more efficient and can
reduce a step of arbitrary length to seconds - dependant on the model
and the refactoring, codebase size etc. Although this likely is better
to be done by a headless service. Since the IDE instance is mostly there
to interact with humans - while not needed as tool for the task itself.
For example: I am not sure how useful it would be if the LLM would
decide to open a refactoring window for the dev after 10 minutes of
iterating on something before continuing with the next 10 minute step.
(btw LLMs do a decent job generating NB's jackpot scripts which can be
piped into refactoring tasks - since those are basically java syntax
with extra sauce)
e.g i told locally running granite4.2_8b via OpenCode to run a build on
a pre existing "hello world" maven project before writing this reply and
it is still contemplating how to reduce the compiler.release property
since JDK 27 isn't in the env. But it looks like its nearly there -
while the GPU fan is screaming from the other room. (-> would have been
faster to ask the IDE where the JDK for this project is ;))
It is easy to forget how much compute it actually requires to change a
few chars compared to running a tool. (I can only encourage everyone to
*try* to run a local model for a trivial task on a rainy day)
Although security wise this can be really quick in "jesus take the
wheel" mode. Letting LLMs run maven builds without locking the pom for
edits is already more than sufficient to cause trouble. Even though this
is the case with or without IDE, if it can use the IDE as tool to edit
the pom it effectively circumvented a harness rule.
btw there are some community plugins available which let you connect to
LLM harnesses and render output in a NB window e.g I found BeanBot at
https://github.com/anandb/nb-complete working pretty well. Although I
have to admit i use the shell (running the harness UI for OpenCode or
others) most of the time.
(I will be mostly helping to stabilize the NB 32 release the next days
so i might not have much time to think about new features)
best regards,
michael
On 10/14/26 15:52, ehsavoie wrote:
> 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://twitter.com/ehsavoie
>
>
>
>
> [1]: https://github.com/apache/netbeans/pull/9712
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: ACP integration
Posted by Anton Epple <to...@eppleton.de>.
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" <mbien42@gmail.com <ma...@gmail.com>>:
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" <jaroslav.tulach@gmail.com <ma...@gmail.com> <mailto:jaroslav.tulach@gmail.com <ma...@gmail.com>>>:
>
>
> 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: dev-unsubscribe@netbeans.apache.org <ma...@netbeans.apache.org> <mailto:dev-unsubscribe@netbeans.apache.org <ma...@netbeans.apache.org>>
> For additional commands, e-mail: dev-help@netbeans.apache.org <ma...@netbeans.apache.org> <mailto:dev-help@netbeans.apache.org <ma...@netbeans.apache.org>>
>
>
> 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: dev-unsubscribe@netbeans.apache.org <ma...@netbeans.apache.org>
> For additional commands, e-mail: dev-help@netbeans.apache.org <ma...@netbeans.apache.org>
>
> 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: dev-unsubscribe@netbeans.apache.org <ma...@netbeans.apache.org>
For additional commands, e-mail: dev-help@netbeans.apache.org <ma...@netbeans.apache.org>
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: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: ACP integration
Posted by Michael Bien <mb...@gmail.com>.
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" <jaroslav.tulach@gmail.com <ma...@gmail.com>>:
>>
>>
>> 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: dev-unsubscribe@netbeans.apache.org <ma...@netbeans.apache.org>
>> For additional commands, e-mail: dev-help@netbeans.apache.org <ma...@netbeans.apache.org>
>>
>>
>> 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: dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: ACP integration
Posted by ehsavoie <em...@gmail.com>.
Hi,
If you want to try what I did:
https://www.dropbox.com/scl/fi/4qayb7mldyjvhx1vvlrjw/NetBeans-dev-dev-c259445dbd3cb48b3014563a560d9e3057653b87-full.zip?rlkey=gp6q17awyhmta8fp6qiskid6o&st=xe0nzmb9&dl=0
Cheers
Emmanuel
Le jeu. 15 oct. 2026 à 11:29, Michael Bien <mb...@gmail.com> a écrit :
> 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" <jaroslav.tulach@gmail.com
> <ma...@gmail.com>>:
> >
> >
> > 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: dev-unsubscribe@netbeans.apache.org <mailto:
> dev-unsubscribe@netbeans.apache.org>
> > For additional commands, e-mail: dev-help@netbeans.apache.org <mailto:
> dev-help@netbeans.apache.org>
> >
> >
> > 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: dev-unsubscribe@netbeans.apache.org
> > For additional commands, e-mail: dev-help@netbeans.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: ACP integration
Posted by Michael Bien <mb...@gmail.com>.
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" <jaroslav.tulach@gmail.com <ma...@gmail.com>>:
>
>
> 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: dev-unsubscribe@netbeans.apache.org <ma...@netbeans.apache.org>
> For additional commands, e-mail: dev-help@netbeans.apache.org <ma...@netbeans.apache.org>
>
>
> 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: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: ACP integration
Posted by Anton Epple <to...@eppleton.de>.
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" <jaroslav.tulach@gmail.com <ma...@gmail.com>>:
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: dev-unsubscribe@netbeans.apache.org <ma...@netbeans.apache.org>
For additional commands, e-mail: dev-help@netbeans.apache.org <ma...@netbeans.apache.org>
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: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: ACP integration
Posted by Jaroslav Tulach <ja...@gmail.com>.
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)
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()
I believe we should extend that class to provide some concepts of
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: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: ACP integration
Posted by Anton Epple <to...@eppleton.de>.
Hi Emmanuel,
The extra cluster is fine for now; it makes sense while things are experimental. Later the generic ACP/MCP modules could go to ide and the Java tools to java - if others agree.
On our side, I got the Java tools to work on the projects open in the IDE instead of on a single workspace folder. That was the prerequisite for plugging them into your McpToolProvider. Once I have your build, I'll open a PR on your branch with a provider for them, and we can remove JavaRefactoringToolProvider.
Toni
Am 14.10.26, 18:24 schrieb "ehsavoie" <emmanuel.hugonnet@gmail.com <ma...@gmail.com>>:
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 <emmanuel.hugonnet@gmail.com <ma...@gmail.com>> 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://www.ehsavoie.com>
> http://twitter.com/ehsavoie <http://twitter.com/ehsavoie>
>
>
> Le mer. 14 oct. 2026 à 17:56, Anton Epple <toni.epple@eppleton.de <ma...@eppleton.de>> 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" <emmanuel.hugonnet@gmail.com <ma...@gmail.com>
>> <mailto:emmanuel.hugonnet@gmail.com <ma...@gmail.com>>>:
>>
>>
>> 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://www.ehsavoie.com> <http://www.ehsavoie.com>>
>> http://twitter.com/ehsavoie <http://twitter.com/ehsavoie> <http://twitter.com/ehsavoie> <http://twitter.com/ehsavoie>>
>>
>>
>>
>>
>> Le mer. 14 oct. 2026 à 16:18, Anton Epple <toni.epple@eppleton.de <ma...@eppleton.de>
>> <mailto:toni.epple@eppleton.de <ma...@eppleton.de>>> 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://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>
>> <
>> 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" <emmanuel.hugonnet@gmail.com <ma...@gmail.com>
>> <mailto:emmanuel.hugonnet@gmail.com <ma...@gmail.com>>
>> > <mailto:emmanuel.hugonnet@gmail.com <ma...@gmail.com> <mailto:emmanuel.hugonnet@gmail.com <ma...@gmail.com>
>> >>>:
>> >
>> >
>> > 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://www.ehsavoie.com> <http://www.ehsavoie.com>> <http://www.ehsavoie.com>> <http://www.ehsavoie.com&gt;>>
>> > http://twitter.com/ehsavoie <http://twitter.com/ehsavoie> <http://twitter.com/ehsavoie> <http://twitter.com/ehsavoie>> <
>> http://twitter.com/ehsavoie> <http://twitter.com/ehsavoie>> <http://twitter.com/ehsavoie>> <http://twitter.com/ehsavoie&gt;>>
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > [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>> <
>> > 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&gt;>>
>> >
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org <ma...@netbeans.apache.org> <mailto:
>> dev-unsubscribe@netbeans.apache.org <ma...@netbeans.apache.org>>
>> > For additional commands, e-mail: dev-help@netbeans.apache.org <ma...@netbeans.apache.org> <mailto:
>> dev-help@netbeans.apache.org <ma...@netbeans.apache.org>>
>> >
>> > 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: dev-unsubscribe@netbeans.apache.org <ma...@netbeans.apache.org>
>> For additional commands, e-mail: dev-help@netbeans.apache.org <ma...@netbeans.apache.org>
>>
>> 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: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: ACP integration
Posted by ehsavoie <em...@gmail.com>.
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 <em...@gmail.com> 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 <to...@eppleton.de> 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" <emmanuel.hugonnet@gmail.com
>> <ma...@gmail.com>>:
>>
>>
>> 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 <toni.epple@eppleton.de
>> <ma...@eppleton.de>> 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" <emmanuel.hugonnet@gmail.com
>> <ma...@gmail.com>
>> > <mailto:emmanuel.hugonnet@gmail.com <mailto:emmanuel.hugonnet@gmail.com
>> >>>:
>> >
>> >
>> > 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: dev-unsubscribe@netbeans.apache.org <mailto:
>> dev-unsubscribe@netbeans.apache.org>
>> > For additional commands, e-mail: dev-help@netbeans.apache.org <mailto:
>> dev-help@netbeans.apache.org>
>> >
>> > 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: dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>>
Re: ACP integration
Posted by ehsavoie <em...@gmail.com>.
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 <to...@eppleton.de> 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" <emmanuel.hugonnet@gmail.com
> <ma...@gmail.com>>:
>
>
> 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 <toni.epple@eppleton.de <mailto:
> toni.epple@eppleton.de>> 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" <emmanuel.hugonnet@gmail.com
> <ma...@gmail.com>
> > <mailto:emmanuel.hugonnet@gmail.com <mailto:emmanuel.hugonnet@gmail.com
> >>>:
> >
> >
> > 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: dev-unsubscribe@netbeans.apache.org <mailto:
> dev-unsubscribe@netbeans.apache.org>
> > For additional commands, e-mail: dev-help@netbeans.apache.org <mailto:
> dev-help@netbeans.apache.org>
> >
> > 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: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: ACP integration
Posted by ehsavoie <em...@gmail.com>.
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 <to...@eppleton.de> 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" <emmanuel.hugonnet@gmail.com
> <ma...@gmail.com>>:
>
>
> 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 <toni.epple@eppleton.de <mailto:
> toni.epple@eppleton.de>> 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" <emmanuel.hugonnet@gmail.com
> <ma...@gmail.com>
> > <mailto:emmanuel.hugonnet@gmail.com <mailto:emmanuel.hugonnet@gmail.com
> >>>:
> >
> >
> > 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: dev-unsubscribe@netbeans.apache.org <mailto:
> dev-unsubscribe@netbeans.apache.org>
> > For additional commands, e-mail: dev-help@netbeans.apache.org <mailto:
> dev-help@netbeans.apache.org>
> >
> > 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: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: ACP integration
Posted by Anton Epple <to...@eppleton.de>.
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" <emmanuel.hugonnet@gmail.com <ma...@gmail.com>>:
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 <toni.epple@eppleton.de <ma...@eppleton.de>> 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" <emmanuel.hugonnet@gmail.com <ma...@gmail.com>
> <mailto:emmanuel.hugonnet@gmail.com <ma...@gmail.com>>>:
>
>
> 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: dev-unsubscribe@netbeans.apache.org <ma...@netbeans.apache.org>
> For additional commands, e-mail: dev-help@netbeans.apache.org <ma...@netbeans.apache.org>
>
> 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: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: ACP integration
Posted by ehsavoie <em...@gmail.com>.
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://twitter.com/ehsavoie
Le mer. 14 oct. 2026 à 16:18, Anton Epple <to...@eppleton.de> 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://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" <emmanuel.hugonnet@gmail.com
> <ma...@gmail.com>>:
>
>
> 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://twitter.com/ehsavoie <http://twitter.com/ehsavoie>
>
>
>
>
>
>
>
>
> [1]: https://github.com/apache/netbeans/pull/9712 <
> https://github.com/apache/netbeans/pull/9712>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: ACP integration
Posted by Anton Epple <to...@eppleton.de>.
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://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" <emmanuel.hugonnet@gmail.com <ma...@gmail.com>>:
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://twitter.com/ehsavoie <http://twitter.com/ehsavoie>
[1]: https://github.com/apache/netbeans/pull/9712 <https://github.com/apache/netbeans/pull/9712>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: ACP integration
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 15 Oct 2026 at 13:03, ehsavoie <em...@gmail.com> wrote:
> Sorry I'm used to having to sign my commits and it didn't seem to be an
> issue in any OSS project before (even those under the Apache umbrella).
> In fact this was required by Eclipse iirc.
It's probably not an issue. Just that by my understanding the meaning
depends on the project being contributed to, and we don't define one.
I've seen it used by people when someone else, or something else (ie.
generative tools), were involved in creating the code. By what you
said, I assume neither applies here? On the other hand, given the
topic, and as Anton mentioned his work was written with AI assistance,
there is a need to capture this information in the submission if it
applies.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: ACP integration
Posted by ehsavoie <em...@gmail.com>.
Hello,
Sorry I'm used to having to sign my commits and it didn't seem to be an
issue in any OSS project before (even those under the Apache umbrella).
In fact this was required by Eclipse iirc.
Cheers,
----------
Emmanuel Hugonnet
Le jeu. 15 oct. 2026 à 12:57, Anton Epple <to...@eppleton.de> a écrit :
> Hi Neil,
>
> Thanks, the ASF / Apache NetBeans umbrella is where I'd like this to end
> up. It is Apache-2.0 licensed already, so nothing stands in the way of
> moving it.
>
> For now, I'd rather keep it where it is for a while: the tools and their
> interfaces are still changing quickly, and I'd like to build some usage and
> let the APIs settle before going through a donation. Also the code is
> written with AI assistance (rather unsurprisingly given the area it's in :
> ) ), so before any donation I'd want to clarify the provenance question you
> raised for Emmanuel's PR for our code as well.
>
> And agreed on keeping the project/workspace discussion in one thread.
>
> Toni
>
> Am 15.10.26, 12:36 schrieb "Neil C Smith" <neilcsmith@apache.org <mailto:
> neilcsmith@apache.org>>:
>
>
> On Thu, 15 Oct 2026 at 11:24, Anton Epple <toni.epple@eppleton.de <mailto:
> toni.epple@eppleton.de>> wrote:
> > That matches what I had in mind for our part. I offered to provide the
> Java tools (usages, refactorings with a compile check, compile errors) to
> an MCP server inside the IDE, and they are already released on their own
> schedule elsewhere (a standalone server and a VS Code extension). It allows
> us to "move fast and break things" unlike we would do inside the NB code
> base.
>
>
> So if we can change that to "their own schedule *here*" then we have
> the potential for moving fast and breaking things, while still having
> the benefit to being under the ASF / Apache NetBeans umbrella.
>
>
> > Shipping them as a NetBeans plugin as well, with the option to merge
> later once things have settled and there is interest, seems the right way
> to me. What would help in the IDE itself are small API additions such as
> the workspace/folder concept Jarda and Michael are discussing, so that such
> plugins don't each have to build it themselves.
>
>
> I'm mostly with Michael's position on being pro-project camp there.
> And keeping groups somewhat orthogonal to that. While still having a
> basic project type that can be used for all these things being
> discussed.
>
>
> Although we also don't make enough of groups supporting configuration
> at the moment - the only thing we have currently is a Maven home
> setting that may or may not work correctly.
>
>
> We should probably keep that part of the discussion in one place, not
> fifteen. :-)
>
>
> Best wishes,
>
>
> Neil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org <mailto:
> dev-unsubscribe@netbeans.apache.org>
> For additional commands, e-mail: dev-help@netbeans.apache.org <mailto:
> dev-help@netbeans.apache.org>
>
>
> 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: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: ACP integration
Posted by Anton Epple <to...@eppleton.de>.
Hi Neil,
Thanks, the ASF / Apache NetBeans umbrella is where I'd like this to end up. It is Apache-2.0 licensed already, so nothing stands in the way of moving it.
For now, I'd rather keep it where it is for a while: the tools and their interfaces are still changing quickly, and I'd like to build some usage and let the APIs settle before going through a donation. Also the code is written with AI assistance (rather unsurprisingly given the area it's in : ) ), so before any donation I'd want to clarify the provenance question you raised for Emmanuel's PR for our code as well.
And agreed on keeping the project/workspace discussion in one thread.
Toni
Am 15.10.26, 12:36 schrieb "Neil C Smith" <neilcsmith@apache.org <ma...@apache.org>>:
On Thu, 15 Oct 2026 at 11:24, Anton Epple <toni.epple@eppleton.de <ma...@eppleton.de>> wrote:
> That matches what I had in mind for our part. I offered to provide the Java tools (usages, refactorings with a compile check, compile errors) to an MCP server inside the IDE, and they are already released on their own schedule elsewhere (a standalone server and a VS Code extension). It allows us to "move fast and break things" unlike we would do inside the NB code base.
So if we can change that to "their own schedule *here*" then we have
the potential for moving fast and breaking things, while still having
the benefit to being under the ASF / Apache NetBeans umbrella.
> Shipping them as a NetBeans plugin as well, with the option to merge later once things have settled and there is interest, seems the right way to me. What would help in the IDE itself are small API additions such as the workspace/folder concept Jarda and Michael are discussing, so that such plugins don't each have to build it themselves.
I'm mostly with Michael's position on being pro-project camp there.
And keeping groups somewhat orthogonal to that. While still having a
basic project type that can be used for all these things being
discussed.
Although we also don't make enough of groups supporting configuration
at the moment - the only thing we have currently is a Maven home
setting that may or may not work correctly.
We should probably keep that part of the discussion in one place, not
fifteen. :-)
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org <ma...@netbeans.apache.org>
For additional commands, e-mail: dev-help@netbeans.apache.org <ma...@netbeans.apache.org>
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: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: ACP integration
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 15 Oct 2026 at 11:24, Anton Epple <to...@eppleton.de> wrote:
> That matches what I had in mind for our part. I offered to provide the Java tools (usages, refactorings with a compile check, compile errors) to an MCP server inside the IDE, and they are already released on their own schedule elsewhere (a standalone server and a VS Code extension). It allows us to "move fast and break things" unlike we would do inside the NB code base.
So if we can change that to "their own schedule *here*" then we have
the potential for moving fast and breaking things, while still having
the benefit to being under the ASF / Apache NetBeans umbrella.
> Shipping them as a NetBeans plugin as well, with the option to merge later once things have settled and there is interest, seems the right way to me. What would help in the IDE itself are small API additions such as the workspace/folder concept Jarda and Michael are discussing, so that such plugins don't each have to build it themselves.
I'm mostly with Michael's position on being pro-project camp there.
And keeping groups somewhat orthogonal to that. While still having a
basic project type that can be used for all these things being
discussed.
Although we also don't make enough of groups supporting configuration
at the moment - the only thing we have currently is a Maven home
setting that may or may not work correctly.
We should probably keep that part of the discussion in one place, not
fifteen. :-)
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: ACP integration
Posted by Anton Epple <to...@eppleton.de>.
Hi Neil,
That matches what I had in mind for our part. I offered to provide the Java tools (usages, refactorings with a compile check, compile errors) to an MCP server inside the IDE, and they are already released on their own schedule elsewhere (a standalone server and a VS Code extension). It allows us to "move fast and break things" unlike we would do inside the NB code base.
Shipping them as a NetBeans plugin as well, with the option to merge later once things have settled and there is interest, seems the right way to me. What would help in the IDE itself are small API additions such as the workspace/folder concept Jarda and Michael are discussing, so that such plugins don't each have to build it themselves.
Toni
Am 15.10.26, 12:11 schrieb "Neil C Smith" <neilcsmith@apache.org <ma...@apache.org>>:
Hi,
On Wed, 14 Oct 2026 at 14:52, ehsavoie <emmanuel.hugonnet@gmail.com <ma...@gmail.com>> wrote:
> I've been playing around to use Agent Client Protocol to connect a coding
> agent into NetBeans.
...
> [1]: https://github.com/apache/netbeans/pull/9712 <https://github.com/apache/netbeans/pull/9712>
I put the needs-discussion label on the PR, but only just having a
chance to follow up myself. I don't have a lot of time for NetBeans
right now, and I've been concentrating the time I do have on getting
us ready for freeze, hence reviewing and labelling.
Thanks for looking into this area. However, I have major reservations
about merging this into the main IDE repository. There may be a few
module changes / moves that should be there though.
IDE and platform releases are large and time consuming, mostly down to
one person (Eric) now that the release team is no longer, and really
it's enough to keep to the quarterly schedule. Pushing updates
between releases is awkward, and with the current way the Maven
releases are architected, overly resource intensive.
Features like this, with both rapidly changing ecosystem and potential
security considerations, feel like they would benefit from a lighter
and more responsive release schedule. It's been discussed in another
context, but I think this is another feature that would be good to
consider releasing via an official plugin repository (ie NetBeans' own
extensions). Being in extra is pointless as it'll never be released.
Not that this appears to be in extra anyway?! Just like Maven plugins
have their own repositories and release schedules, let's consider
which features of the IDE are better addressed in that way?
I'm also curious what the "Signed off by" line on each commit means
for the provenance of the code in this PR?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org <ma...@netbeans.apache.org>
For additional commands, e-mail: dev-help@netbeans.apache.org <ma...@netbeans.apache.org>
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: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: ACP integration
Posted by Neil C Smith <ne...@apache.org>.
Hi,
On Wed, 14 Oct 2026 at 14:52, ehsavoie <em...@gmail.com> wrote:
> I've been playing around to use Agent Client Protocol to connect a coding
> agent into NetBeans.
...
> [1]: https://github.com/apache/netbeans/pull/9712
I put the needs-discussion label on the PR, but only just having a
chance to follow up myself. I don't have a lot of time for NetBeans
right now, and I've been concentrating the time I do have on getting
us ready for freeze, hence reviewing and labelling.
Thanks for looking into this area. However, I have major reservations
about merging this into the main IDE repository. There may be a few
module changes / moves that should be there though.
IDE and platform releases are large and time consuming, mostly down to
one person (Eric) now that the release team is no longer, and really
it's enough to keep to the quarterly schedule. Pushing updates
between releases is awkward, and with the current way the Maven
releases are architected, overly resource intensive.
Features like this, with both rapidly changing ecosystem and potential
security considerations, feel like they would benefit from a lighter
and more responsive release schedule. It's been discussed in another
context, but I think this is another feature that would be good to
consider releasing via an official plugin repository (ie NetBeans' own
extensions). Being in extra is pointless as it'll never be released.
Not that this appears to be in extra anyway?! Just like Maven plugins
have their own repositories and release schedules, let's consider
which features of the IDE are better addressed in that way?
I'm also curious what the "Signed off by" line on each commit means
for the provenance of the code in this PR?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists