On 10/11/26 16:39, Jan Lahoda wrote: > > > On Sun, Oct 11, 2026 at 1:24 AM Michael Bien <[email protected]> wrote: > > On 10/8/26 08:27, Jan Lahoda wrote: > >> what gets opened. > >> > >> tbh I am a bit confused why there is such big focus on trying to > >> automatically open everything within a folder (it might be > distracting > >> from the actual underlying improvements). It is easy to > demonstrate that > >> it is a very bad idea to try that performance wise and likely > security > >> wise too. (performance PRs are welcome btw if backed by > measurements) > >> > > My personal opinion: > > If a user explicitly says "I want to work with stuff in this > folder" (e.g. > > by opening it as a project/"workspace folder"), then we should > try to make > > things work for them. In practice, that means indexing the stuff > in the > > folder (some things work reasonably with on demand indexing, but > not all), > > and project open is a way to make sure indexing happens. > I am curious how that would work in practice. The generic folder is > unstructured by design. What would NB do if it finds a jar or a json; > e.g once in the index. what would it associate it with? > > > What I had in mind was that we'd discover projects under that > directory, and open them. (And also open a project that would be owner > of that folder, if any, although that is probably niche.) > > This is, per my understanding, exactly what the VS Code extension is > doing for Java projects.
I see. I initially read it as argument for having to code scan the folder itself But what was meant is to (correct me if I am wrong) 1) discover projects and open them 2) the act of opening the folder does the code scanning just like it would normally 3) the folder itself doesn't necessarily have to be scanned for other content since things are delegated to 2) so there is no reason yet why the projects must be open from the beginning > > > > "Real" projects have specific source roots, build structure and config > based on their project type, which allows NB to create relationships > between artifacts during index queries. > > To quote a movie line: "i have a bad feeling about this" > > If there would be a challenge to come up with a way to convert > potential > multi click CVEs into 0 click CVEs, running annotation processors and > other things in arbitrary folders without much user interaction > would be > a hot contender ;) > > > We already have some "trust" for projects, and we may need an explicit > "trust" for folders like this in any case - at least assuming a folder > like this would be sent as a workspace folder to LSP servers. This is a factor why the distinction between open/closed matters. The trust check box doesn't do that much for maven right now and it is only on the project open dialog atm. The opening project step is a step before more things happen - we might regret that if this step is effectively removed (by automating it away) since this is a good place to add further checks. > > > > > If we let the user "open" a folder, but don't index, and force > the user > > manually select which projects should be open, then I am not > sure how big > > an improvement is that compared to the current state. The user could > > already open the projects (if they exist). > > i think the improvement to have chosen folders attached to project > groups (be it via project impl or other ways) would be already pretty > significant IMO. > > > I guess I wonder what is the significance of improvement, where I can > add an arbitrary folder to the project group, but nothing else happens > except the folder is on some list of folders. I see it might be useful > for use with LSP servers and related technologies (as a workspace > folder), but outside that, in "pure" IDE, what's the advantage? Is it > just because Favorites are not switched when Project Groups are > switched? Because it sounds a lot like a folder inside Favorites. I guess favorites would be somewhat comparable but its more integrated into projects. (Favorites is more like a static bookmark collection) - it could be a "sidecar" for a project (the path indentation would make it attach to it most likely) - it could be a parent folder for a project group with everything in it (e.g netbeans/ide/ or semester1 or my_apache_projects/ and you open what you want) - it could be used for anything which doesn't have project support yet or scripts etc > > > > The fact that it could be a root folder for one or more projects > is also > interesting (the new sub-path tree indention makes that an option now) > > Opening projects is also pretty easy. If it isn't easy enough and > there > are actions missing e.g "open everything within folder" we could > add it > I suppose. > > Nice thing about this: the project group remembers what was open and > what not - so it builds on top of existing functionality. > > > we could flip the point of view too: > > Maybe someone wants to work only on a handful of sub projects, why > would > it be required to open everything just to close uninteresting projects > again? > > > If someone wants to and has the knowledge to work on a limited set of > projects, then there's nothing preventing them from opening just the > projects they want, no? I mean, we don't want to remove any > functionality, right? if we don't want the described person to use that feature - then yes - the old way would remain functional :) > > I suppose two reasons for adding the ability might be support for LSP > servers (i.e. sending them as workspace folders to the LSP server and > alike); and to make work with projects simpler. Just adding a folder > into the list with nothing more helps at most with the first one. i have nothing against adding the *ability* to auto open things within a special folder. I am just confused why it is seen as default mode for this feature given how much headache this produces. It is also inconsistent to existing defaults, like the "open required projects" checkboxes (one is after git clone the other on the open project dialog if it has sub modules and both are off by default). (if VSCode or agents need this since they have other guardrails configured I am sure a way could be found to configure the default) -mbien > > Jan > > --------------------------------------------------------------------- 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
