This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Situation: I use to excessively work with different project groups (mainly "folder-of-project" groups, some others as well) grouping together more or less huge amounts of projects. At the moment, I can switch between these groups at runtime when the IDE is up which, however, always takes a considerate amount of time especially if the group to be switched to is a little larger. Worst situation is that I immediately want to switch to another "large" project group whereas the one the IDE automatically will open at startup also is rather large - this is likely to take some time. Proposed solution: If configured (enabled?), prompt the user to choose which project group to open at startup. This surely would be a great help here.
raising priority of this one. scenario given, having two project groups, 52 maven2 projects each, switching between the two of them takes 5 .. 10 minutes (including "scanning projects..." and everything else) until the IDE is usable again. this is not pleasant. :(
again raising priority of this one. state of work: 11:30 : switched from my main project group (50+ maven2 projects) to a "testbed working group" (a handful of projects, maven2 as well as some others) ... 11:45 : switch _seems_ done... tried opening / running a .java class. "Scanning projects..." started. ... 12:15 : "scanning projects..." still taking place. Overally, working like this is pretty hard. If the "switch project group" operation doesn't reliably work, maybe either the "choose-project-group-on-startup" option should be around, or the project group feature should be removed altogether. At the moment, it's simply unusable with larger groups.
Reporter's problems are related to the Java scanner, not project groups or other aspects of the generic project system. See e.g. http://wiki.netbeans.org/ScanOnDemand Any specific bugs in scanning (such as new scanning occurring when a file from an open project is opened in the editor even though scanning looked to have been done already) which are _reproducible from scratch_ should be filed separately under 'Java' / 'source'.
The "scanning projects..." problem (reproducible from scratch, by the way, using a recent NetBeans nightly build and creating a new, decently sized project group) is just what makes lack of this feature most painful at the moment. However, if using project groups after all, and given that opening "large" project groups always is likely to take some time, having to open a large one (the last one in use) just for the sake of then switching to the one actually needed / desired to work with is not really convenient. :) I'll have a look at ScanOnDemand nevertheless and see whether it makes "scanning projects..." related trouble a little less annoying.
You can always use separate user directories as a workaround. Or simply switch the project group to "(none)" before closing the IDE the last time. Always prompting at startup is likely undesirable, and we are generally reluctant to add new global GUI configuration options. Perhaps individual project groups could have a configuration checkbox labeled something like "do not reopen after restart" which you could check for groups of unwieldy size. BTW as to "creat[e] a new, decently sized project group" - if you choose to file a bug in java/source be sure to provide real instructions to reproduce. I open what I consider "decently sized" project groups all the time and it certainly does not take anywhere near 45 minutes to scan. Best is an actual ZIP file of the projects in the group, fully configured and ready to open by anyone who downloads it. Also need is information about your machine: OS, processor speed, disk speed, RAM; and NB info: version, enabled plugins, JDK version, heap settings. Much of this environmental information is present in your log file, as well as detailed measurements of the number of source roots being scanned and how long each took.
Bug #168578 would need to be addressed before adding any kind of startup-time group selector (whether GUI, or --group from the CLI).
Can try to address particular performance problems associated with opening or switching project groups, so that it costs little to start up with one and then switch to another, but do not intend to implement this as filed.
Then maybe the group feature should generally be evaluated. Actually, by now I have given up on using it altogether because it is not usable the way it is now. The workaround provided (switch project group to "none" before closing) is not really satisfactory. Btw I do not think this is really associated with java/source as the desire to have project groups selected before/during IDE startup due to performance reasons is just my very special use case. Regardless of performance issues, I would love to use the NetBeans group feature to, in example, have two different branches of my projects checked off SVN and be capable of telling the IDE which one I want to work with at start-up. So, simply speaking, I would rather file this against "usability" than "java/source" because, to me, it simply seems a matter of making the IDE a little more usable in a given field of view. Despite the fact that the "workspaces" concept generally is flawed, Eclipse does rather good here, and I think this is something at least worth considering some improvement... Re-opening this, feel free to move it to a better product/component (didn't find "usability" in the list here, and don't know how to make this a 69cat issue).
(In reply to comment #8) > Then maybe the group feature should generally be evaluated. Actually, by now I > have given up on using it altogether because it is not usable the way it is > now. The workaround provided (switch project group to "none" before closing) > is not really satisfactory. > > Btw I do not think this is really associated with java/source as the desire to > have project groups selected before/during IDE startup due to performance > reasons is just my very special use case. Regardless of performance issues, I > would love to use the NetBeans group feature to, in example, have two different > branches of my projects checked off SVN and be capable of telling the IDE which > one I want to work with at start-up. So, simply speaking, I would rather file > this against "usability" than "java/source" because, to me, it simply seems a > matter of making the IDE a little more usable in a given field of view. Despite > the fact that the "workspaces" concept generally is flawed, Eclipse does rather > good here, and I think this is something at least worth considering some > improvement... Re-opening this, feel free to move it to a better > product/component (didn't find "usability" in the list here, and don't know how > to make this a 69cat issue). I agree to most of this comment. I find project groups extremely useful, but it's annoying to start the IDE and have to wait until the last opened group loads, when I know I'll be working with a different one. Probably a better approach to solve this problem is to add a command line option to select the desired group on startup (Bug #130367). Then you could just have several scripts/icons to start with the group you want.
*** Bug 130367 has been marked as a duplicate of this bug. ***
core-main #3e6a8dcd7be0 (--help for details).
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/3e6a8dcd7be0 User: Jesse Glick <jglick@netbeans.org> Log: #168556: adding new CLI option --group to open/close project groups during startup.
Neat, thanks! :) As far as --open-group is concerned, this works exactly the way it should. Only thing eventually a little confusing (yet not too painful) is that "--list-groups", apart from doing a text dump, is likely to fire up the IDE in the last opened project group. Is this intentional?
(In reply to comment #13) > "--list-groups", apart from doing a text dump, is likely to fire up the > IDE in the last opened project group. Is this intentional? I could not find a good way to prevent it from launching the IDE if not already running. The intent was to call this with the IDE running, in which case it is harmless.
Fine with me. It's an advanced feature anyway, and the implementation given is really helpful. Fix verified.