On 10/15/26 11:29, Michael Bien wrote: > I am still in the pro-project camp since it seems to be the easiest > solution while being well supported :) > > LLM harness permissions are path based and map well to projects or repos. > > (in a nutshell: you start a session and that is your base path by > default, everything outside it is external and requires extra > permissions, as you said everything is named using relative paths since > that is all the session knows)
short note since I was reading through the code of bean bot: if you ask it to list all tabs and some opened files are outside of the project of the session -> it won't see those (other actions work similarly). Basically exactly what we talked about. If any folder could be a project it would likely continue to work without any adjustments to new concepts. It would see a project which happens to have more projects in it. not to mention: you could have two agent sessions working on two folders at the same time without knowing from each other. Both could be opened in the same project group. With the workspace proposals this would be hard to do since they were essentially a side grade of a pg. (nb can open one at a time) (it does still see absolute paths but that would be difficult to hide from NB's POV since there are simply too many FileObjects, Files, Paths, Strings etc everywhere. It could also ask tooling e.g maven) -mbien > > It could be a new project type with the primary job of representing a > path. It could be the root of a pg, or anywhere else. I suppose it would > be pretty easy to add a method which returns all pgs which have a > project at their root? > > the "Folder of Projects" pg option could be adjusted accordingly to > create a .. project folder ;) in a regular group and this would also > allow to add base folders to existing pgs (at root or anywhere else). > > -mbien > > > On 10/15/26 09:50, Anton Epple wrote: >> Hi Jaroslav, >> >> Thanks for the offer, I'll take you up on it ��. From our perspective a >> "Workspace API" would be grand! Here are concrete use cases from our MCP >> server. Each one is something we had to build ourselves, around OpenProjects: >> >> 1. Workspace folders and paths. Agents name files relative to "the >> workspace". We need its root folders to resolve and display paths. Inside >> the IDE there is no such notion, so we fall back to absolute paths. >> 2. Opening a folder. Given a folder, find its projects: the folder itself, >> its contained projects, or projects a few levels down (a repository whose >> build sits in a subfolder). We wrote that search ourselves. >> 3. One readiness signal. "Projects open, class paths registered, indexing >> done." Large Maven workspaces register class paths in stages. On GlassFish, >> a usage search right after the first scan found 60 of 73 files. We now wait >> until indexing has been quiet for 5s and re-read the source roots. >> 4. More than one workspace per IDE. In nbcode, every LSP client has its own >> projects, served through Lookups.executeWith. An agent connecting to the IDE >> needs the same: its own workspace, not the global OpenProjects. >> 5. Workspace trust. Gradle projects are only loaded after a trust question, >> which nobody can answer headless. We set the global execution rule in our >> own userdir. A per-workspace trust (like VS Code's) would fit agents much >> better. >> 6. External edits. Agents write files directly. Before answering, we refresh >> the workspace folders. A workspace-level "refresh and wait until the index >> caught up" would replace that. >> >> 3 and 4 are the ones that would help most. >> >> Thanks, >> Toni >> >> Am 15.10.26, 08:46 schrieb "Jaroslav Tulach" <[email protected] >> <mailto:[email protected]>>: >> >> >> Hello guys, >> I am glad you decided to help NetBeans catch the AI train! >> >> >>> The one real piece of work is on my side: our tools currently open a >>> workspace folder themselves. Inside the IDE they should use the projects >>> that are already open. I'll adapt that, and then open a PR on your branch >>> with the provider, as you suggested. >> There is a discussion [raging >> nearby](https://lists.apache.org/thread.html/jx5ox9pjltzo2r16gqljo7zqvysywhql >> <https://lists.apache.org/thread.html/jx5ox9pjltzo2r16gqljo7zqvysywhql>) >> where I claim NetBeans should adopt a concept of a workspace (e.g. >> project group) more. Support for tools like MCP, LSP, etc. is exactly >> the reason why having a "pg" as a 1st class citizen would help such >> tools to integrate with NetBeans. >> >> >> There already is >> https://bits.netbeans.org/dev/javadoc/org-netbeans-modules-projectuiapi-base/org/netbeans/api/project/ui/OpenProjects.html#getActiveProjectGroup >> >> <https://bits.netbeans.org/dev/javadoc/org-netbeans-modules-projectuiapi-base/org/netbeans/api/project/ui/OpenProjects.html#getActiveProjectGroup>() >> I believe we should extend that class to provide some concepts of >> https://code.visualstudio.com/api/references/vscode-api#workspace >> <https://code.visualstudio.com/api/references/vscode-api#workspace> - I >> am looking for real use-cases to justify such changes. >> >> >> If there is anything to add there to make your train catching easier, >> please spell it! >> -jt >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> <mailto:[email protected]> >> For additional commands, e-mail: [email protected] >> <mailto:[email protected]> >> >> >> For further information about the NetBeans mailing lists, visit: >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >> <https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists> >> >> >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> For further information about the NetBeans mailing lists, visit: >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
