Let --close-group empty the project list

[jtulach]

Use netbeans --close-group to start the IDE with an empty set of projects.

Motivation

• Often, when working on multiple projects, I want to make a project switch
• however when running just netbeans
  • it opens the previous projects and starts scanning them
  • that's the last thing I want to see
  • I'd like a way to start with fresh (empty) project list and open whatever I want to work on
• I know some people are using --userdir for that
  • but I am fine with my settings, I just don't want to burn the CPU on scanning projects I don't want
• after thinking about various UI options, I guess using existing --open-group CLI option would be good enough

Feature

• since 9eb0fce invoking netbeans --close-group now always starts with an empty project list
• some unit tests added in 606ab1a

[neilcsmith-net]

Why not a --new-group option? This could get a little annoying if you have a propensity for typos! If we do add to the existing option, the description should be updated to cover it.

The --close-group option does cover some of your scenario. That might be better enforcing an empty group anyway?

Aside - that --list-groups doesn't exit is annoying too looking at this. If I put that in I want to see what I can choose, not launch the IDE too.

[eppleton]

Why not a --new-group option? This could get a little annoying if you have a propensity for typos! If we do add to the existing option, the description should be updated to cover it.

True, typos might be a problem ( at least for me ;-) ) We could print a line like "Created new empty project group 'X'" to the console via env.getOutputStream() to make this more visible. (or use "--new-group")

[mbien]

• however when running just netbeans
  • it opens the previous projects and starts scanning them
  • that's the last thing I want to see
  • I'd like a way to start with fresh (empty) project list and open whatever I want to work on

i use --close-group often. It starts in group none which should be empty by default.

Now combine it with a path, like: nb --close-group ./apache-roller/* and you are a click away from a new group with a set of projects / folders already opening.

What I thought about was --tmp-user which would clone the config into tmp and start with --close-group implicitly set. Would be the quickest way to get a new NB instance based on your current config. Never got to implement it in https://github.com/mbien/nb-launcher which is used for experiments - probably should give it a try before release phase since it makes testing easier. (its not without problems, e.g mvn remote index would start downloading again etc)

[neilcsmith-net]

i use --close-group often. It starts in group none which should be empty by default.

Mine is rarely empty. As said above, I wonder whether the default for that option, and for switching to none in the UI, would be better as a clean slate.

What I thought about was --tmp-user which would clone the config into tmp and start with --close-group implicitly set ... (its not without problems, e.g mvn remote index would start downloading again etc)

Aside - need a way to share some of the cache? That could be tricky, but sharing the Maven indexing would be good. Something to discuss elsewhere.

[jtulach]

Here is the new approach:

• let --close-group not only close the group (if any)
• but also empty the list of projects
• if I got it right, that's exactly what @neilcsmith-net hinted here:

The --close-group option does cover some of your scenario. That might be better enforcing an empty group anyway?
@mbien wrote and Neil replied:

i use --close-group often. It starts in group none which should be empty by default.
Mine is rarely empty. As said above, I wonder whether the default for that option, and for switching to none in the UI, would be better as a clean slate.

• Exactly! Clean state is better.
• when @jglick introduced the project groups:
  • Jesse (probably) wanted to keep compatibility with the prior state
  • e.g. when one opts for groups and the opts out by closing them...
  • one gets to a previous state just like groups support wouldn't exists
• that made some sense but it shows its limits these days - let's change it

[neilcsmith-net]

Yes, this is what I meant. I should make my "hints" more explicit! 😆

Ideally this should be handled in open too when projectsLoaded == true.

Interestingly, there's a TODO matching this behaviour in there already.

netbeans/ide/projectui/src/org/netbeans/modules/project/ui/groups/Group.java

Lines 579 to 582 in c25d20f

	//TODO switching to no group always clears the opened project list.
	Set<Project> newOpen = g != null ? g.getProjects(h, 10, 100) : getProjectsByPreferences(noneGroupPref, h, 10, 100);
	final Set<Project> toClose = new HashSet<Project>(oldOpen);

[jtulach]

Here is an ideological justification of the behavioral change of --close-group with an outline of the future:

Group Centric View

• Let build NetBeans projects and file view around the concept of a ProjectGroup .
• a group is a set of projects (same as now) with few implementations AdhocGroup, DirectoryGroup, etc.)
• there is always a single opened project group in the NetBeans IDE
  • there is a way to listen and obtain the current group
• users can create new groups and switch between existing groups
• the default group (none in current implementation) is switch non-persistent
  • e.g. when switching to it, it starts empty, as a fresh group
  • it keeps its project list on shutdown/restart however
• developers can query the current group, observe its changes and get list of Project in the current group
  • there already is getActiveProjectGroup()
  • created by 6a3ae0aed18ca3e6a7af31901311ee63bd798351used only by Maven support for not clear reasons
  • let's enhance ProjectGroup with additional getters to look alike workspace and serve similar purpose
  • where workspaceFolders would be getProjects(), isTrusted(), maybe textDocuments to deal with opening previously opened editor views on group switch
• shift the UI towards the group centric view while keeping the flexibility for expert users

[neilcsmith-net]

Agreed! With the obligatory, that discussion really belongs on dev@ 😄

created by 6a3ae0aed18ca3e6a7af31901311ee63bd798351used only by Maven support for not clear reasons

I intended to bring this up in the dev@ discussion that Groups can have different settings. Maven support can theoretically have a different Maven Home for each group configured under group properties. I think this is for that. Not sure how well we test that feature, and not that useful compared to pushing mvnw anyway.

Still, anything taking an enhanced group perspective can probably look to provide more group oriented settings available, and provide an easier UI for them.

[mbien]

sounds good

[neilcsmith-net]

Tested a build. Seems to work great. Thanks!

Hopefully @mbien is still OK with the extra change. I think it makes sense for the UI to work like this, and one less TODO is always a good thing!

You might want to remove the TODO comment though when squashing this. 😄