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?
"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 ;)
> 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.
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 the numbers seem a bit too high
> (like for NetBeans), we don't open the projects, and show some kind of a
> warning telling the user working with the whole folder at once might be
> problematic,
right. I mean it could be a project group setting. AUTO_OPEN.{NEVER,
WHEN_FEW, ALWAYS}.
NEVER should be default for our own sanity IMO - esp during rollout.
(default would be somewhat analog how maven/gradle sub projects work
right now when parent opened)
best regards,
michael
---------------------------------------------------------------------
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
