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.
When a new project is loaded in Netbeans 4.0 beta2, it is added to project tree. This is different than how other IDEs (such as Visual Studio .NET or earlier versions of Netbeans) treat projects. Quite often, developers work on a set of related-projects together that logically form a super-project (or Solution in terms of Visual Studio). A developer often works on a number of these super-projects concurrently, or need a way to save or load them up. Netbeans needs to provide ability to do so.
Has been considered, though no current plans to do so; might never do so, TBD. See http://projects.netbeans.org/buildsys/design.html#portfolios Note that for project types with a clear notion of containership (e.g. in J2EE), this RFE is unnecessary since the master container project (e.g. EAR project) already has all the contained projects as subprojects. So you just need to open the master project and leave on the checkbox "Open Required Projects". Note also that it is technically possible currently (though not apparent from the UI at all) to make an placeholder project in an arbitrary location, of freeform type, which has dependencies on an arbitrary set of other projects (whatever their logical relationship), and thus you can open the placeholder and get all the other projects opened.
*** Issue 46095 has been marked as a duplicate of this issue. ***
*** Issue 52079 has been marked as a duplicate of this issue. ***
Was also suggested to just have named snapshots which enumerate open projects. You can save the current open project list as an existing or new snapshot, or load an old snapshot.
*** Issue 56501 has been marked as a duplicate of this issue. ***
*** Issue 54088 has been marked as a duplicate of this issue. ***
Would probably also subsume issue #55176 and issue #57432.
Looks like there is a prototype in contrib/poorMansPortfolios of a simple "snapshot" or "grouping" feature. I have not evaluated it yet.
*** Issue 68619 has been marked as a duplicate of this issue. ***
Jano: I would like to get some comments on a new module, contrib/projectgroups, which should be available on Dev AU in a day or two. It is called "Project Groups". Do not confuse it with the module contrib/poorMansPortfolios which is also called "Project Groups" and has been on Dev AU for a long time; the new one has a long description beginning "Permits grouping of projects and quick switching between groups. ..." The old module has certain advantages but it has a somewhat complicated UI including a new window, displays logical views of nonopen projects, and does not make it quick enough to just switch from one project set to another. For these reasons I decided it was better to start from scratch. I don't have a written UI spec yet but if you look under the File > Project Group submenu where all the UI lives, it should be mostly self-explanatory. You can make a new group in one of three modes and then switch to an existing group, or perform some simple maintenance operations on the selected groups. Switching to a group just opens its projects (and closes other projects). Group definitions are stored in the userdir (under config/Preferences/org/netbeans/modules/projectgroup/ if you are interested). I think this module should satisfy most people's idea of what a project group should do, with a pretty simple UI and not much code. No changes in other modules are required. Can write up a formal UI spec and proposal if you think this is the right direction.
I tried it and I think that's exactly what most users need - lightweight switching between group of projects (with a few UI tweaks). Comments: - I'm not really sure about the different types of groups - free, master project, folder. The fact that each group behaves differently when I open/close projects later and switch groups is strange. Also there's no way to tell later on what is the type of selected group. I think we either should have just the free group or we permit to view (and change?) group type in some kind of "Edit Group Properties..." dialog. - If there's only the free group, we can still provide other ways how to start this group (main project with dependencies, folder containing projects). - Also the fact that there can be *no* group is a bit weired. Because if I create one group I suddenly modify this one group by opening/closing projects. Maybe there should be something like "default- group" which is basically a free group. - It should be possible to start an empty group if I have some projects open.
"each group behaves differently when I open/close projects later and switch groups" - not sure what you mean? Whenever you select a group, it makes sure that the projects defined in that group, and only those projects, are open. (It also adjusts the main project according to the group's setting for that.) The group types other than free are important, I think. The subprojects group lets you e.g. open all WARs etc. in an EAR without needing to ever change the group's definition. The subfolders group lets you e.g. open all projects in a VCS root even if new projects are added later. I will try to add a dialog to let you see the group's settings. I'm not sure that changing anything about the group (other than its display name) is valuable, but can integrate the Update, Rename, and Remove actions into this dialog. "if I create one group I suddenly modify this one group by opening/closing projects" - not true; if you have a free group open you may update it explicitly with your current set of open projects (and main project) but this is never done automatically. "It should be possible to start an empty group if I have some projects open." - thus closing all currently open projects? Easy enough I guess.
Option to make empty (free) group in CVS; will be 1.2 on Dev AU.
+1 on keeping the master project/folder types. the dynamic updating of the group based on current project(s) state is more versatile, flexible and natural that explicit selection of each project. form a maven perspective the master project notion exactly matches the maven notion of a multiproject with modules (subprojects).
Check out 1.3 on Dev AU. I changed a bunch of the UI, including - feature to automatically track open projects, for free groups - all groups automatically track main project - Properties dialog lets you configure some (not all) aspects of a group BTW I found and fixed a couple of bugs in the Preferences storage in recent dev builds, so try to use a new dev build with fixes in this area - otherwise you may find new groups not appearing or deleted groups not disappearing.
My biggest concern is that project groups don't reflect opening/closing projects (except the free group if it is set to do so). Consider the following scenario: The user creats a new "master project" group. Creates a new project A and opens exsiting project B. Switches to another group and back. Now projects A and B are not there. That is unexpected IMO. I would expect that I get back to the same setup of projects as when I left the group. The fact that I say I want all required projects open in the master group doesn't mean I don't want newly created/opened projects opened with the group. I think that updating group automatically should not be property of free group only. I would expect something like this: --- (o) Free Group [x] Start with Currently Open Projects ( ) Main Project and All Required Projects Main Project: |_______________________| [ Browse... ] ( ) All Projects Beneath Folder Folder: |_______________________| [ Browse... ] [x] Update group with additionally open and closed projects Name: |_________________________________________________| --- Or even better without the update check box at all. So all the groups would behave the same - update the group automatically. Another thing I would expect is that the group remembers files open in the editor. But that's a different issue.
Re. "extra" projects - I don't think what you are requesting makes sense. If you have a group defined to be "Project X and all its subprojects", opening it should always open exactly those projects, IMHO. If you happened to open some unrelated projects temporarily, fine, but they should not be part of the group definition. Consider the converse, that you close some of the subprojects of X (or even X itself!) - it would be surprising if those never appeared again. If the definition of other group types were changed as you suggest, then they would in fact just be free groups initialized to an arbitrary set of projects which happens to be all subprojects of X, or all projects inside D. Or the definition of the group would be quite complicated - "those projects which are subprojects of X / inside D, plus those nonmatching projects which were explicitly opened layer, minus those matching projects which were explicitly closed later"; you would not be able to keep track of which projects are "supposed" to be there and which are accidental, and you would need an even more confusing "Reset" button somewhere. Re. tracking files open in the editor - see issue #87552.
I see your point. That's why I would again suggest to keep just the free group. The "master" and "folder" groups should not be represented with radio buttons. The way they behave right now, it's more like "Open Project Group", not "Switch to Project Group". The free group is correctly represented by radio button. A free group is selected and I modify this group by opening and closing projects. If I switch to another group and back I'm in the same state as when I left the group. But if I switch to a "master" group, and open a project, I'm no longer in the "master" group state IMO, because the group of open project is not the same as project contained in the selected master group. The radio button should not be selected. I, for some reason, find combining those 2 approaches to groups (free vs "master and folder") confusing. Also what is the real benefit of "master" and "folder" groups? Let's say my colleague commits a new web module or library project into CVS and I do checkout and it automatically appears in the project explorer? I'm not sure how important is this scenario, but I feel it doesn't happen very often. Also I would like to see how many NB developers would use free group vs master and folder. What are the projects typically open in project explorer? What would be the overhead effort if they have to use free group instead of master/folder group?
I posted 1.4 of the module. It continues to use radio buttons as I think this most closely captures the notion that - for the most part - you have a few groups of projects, which you switch between, and it would be strange not to be able to see which group you last switched to. However the selected radio button menu item is disabled in case the group's project list exactly matches what is already open anyway; it is enabled in case selecting that menu item would really change something (open and/or close some projects). For a free group with the Automatically Synchronize checkbox left checked, the selected radio button menu item is always disabled, since it always tracks what you have open anyway. (Also: for a free group that is manually synchronized, I fixed the Synchronize Now button to be disabled unless it would have an effect.) Re. benefit of master and folder groups - it's pointless if you have only a handful of projects. More likely to be used in situations where the group contains dozens of projects, probably developed by a team, and keeping track of them all becomes a significant burden. For example, if I want to have a group representing all 200+ NB modules in the standard distro, this is best done by making a master group based on the nbbuild freeform project, which is designed to have a dep on every module project - there is no way I am going to remember to include some module added a couple of weeks ago by someone else (or to remove one which was obsoleted). However if you think the master & folder group types contribute more UI bloat than usefulness, I could - delete these features entirely - enable them in the New Group dialog only with some nondefault startup switch for people who know they want this - hide them by default in the New Group dialog unless some Advanced>> button is pressed Similarly for the Automatically Synchronize checkbox (i.e. the option to turn it off) - can be left as is, deleted, hidden by default, etc. I think the manual synch mode can be valuable if you have a group that you are maintaining for a long time and whose contents you want to keep stable, but you also occasionally open some other project to take a peek at something which you do not expect to work on generally. Therefore the group is like a snapshot of projects you can save and restore.
I played with it again and the free group (automatically synchronized) behaves exactly as I expect it to behave. It's a snapshot of what I work on - I can switch to some other group and back. Fine. I understand the purpose of master and folder groups, but still the fact that it doesn't open all projects that were open the last time is a problem IMO. When I switch from group A to group B, it doesn't mean I'm done with my work in group A. Maybe I just had to interrupt my work on group A (which contains branched projects or completely different application) and wanted to get back in a few hours. But when I get back all temporary open projects, or newly created projects not yet with properly set up dependencies are gone closed. I'm not saying this would happen very often, but it's inconsistent with what I call "expected" group behavior. ;-) Now in your example of nbbuild project. Why is it really needed to have all NetBeans projects open? For refactoring? I can actually do that by opening nbbuild with all dependencies. Even more, if the group only checks for dependencies when I manually switch the group (or re-select), then I have to do this manual step before each refactoring. I think we did a survey once and majority of respondents claimed they work on a small set of projects. I cannot find the survey results so I hope I haven't just made it up ;-). I personally would suggest to start with automatically synchronized free group and keep the other groups available on a switch. If users request the other "intelligent" groups and try the switch and are happy with it, we can then consider making it available for everyone. That's my opinion.
OK, I posted 1.5 of the module. By default, the GUI only offers autosynch free groups (does not offer any other choices). You can choose advanced mode, for the full behavior, via a checkbox menu item. This should make the advanced mode discoverable but keep it out of the way otherwise. If we are able to gather any usage data and it seems no one needs the advanced group types then they should be removed.
BTW I added integration with the UI Gestures Collector (on Dev AU); the project groups module will now (1.6) record when you - turn advanced mode on or off - select a new group (with some details about what kind of group it is and how big)
Also adding (1.7) to Projects tab context menu.
I wrote up a formal UI spec, please review.
If you want actual feedback about the advanced features, you need to turn them on by default - otherwise the answer is a foregone conclusion.
I like Borland C++ Builders notion of a project group. You have different project types same as NB. The project group is nothing more than a logical grouping of the projects with options for building and linking the projects. It could use some features and be easier to use though. Which I think NB could do. For instance, lets say we have two projects (in the business sense). These two projects have sub-projects. Each of which is a standalone application, yet they are all installed in the same icon or application group when they are installed on the end users computer. Basically they all comprise a release, so they will all be built together, yet they do not have to have dependencies upon each other or they might. These project groups are something you save in a separate file or project folder. They link relative to these projects or the projects can be linked by hardcode (same as jars in NB projects). So lets say we have a hypothetical CRM. We have separate tools. The main application. Simple CRM (fictional in this instance...not sure if one exists by this name or not...just for example). --Simple CRM Project Group ----Simple CRM Client (Project) ----Simple CRM Server (Web Project) ----Simple CRM Report Designer/Runner (Project) ----Simple CRM Report Server (Web Project) ----Simple CRM Common Library (Project) All of these will be worked on at the same time possibly or not. You can open the project and work on it by itself and see it's dependencies, or you can open the group and work on all the projects in the group. You can then build all the groups or each one independently unless it is dependent on another in which case they would have to be built. You can have multiple groups in a given project (business sense) as well. It seems to me if these could be saved in files or project folders like projects then the groups can be checked out of source control and test releases or what ever could more easily be built. The entire group could be built from one entry point. Maybe when one goes to add projects to a group then just allow them to "Add Groups/Projects Under Directory" and "Add Group/Project". That would address the folders group idea. If it is something that should contantly be adding projects and groups found under the path then maybe "Add Groups/Projects Directory" From the IDE perspective it would look like this instead of a groups tab (groups would have their own icon as in the module Jesse has written): ----------- |Projects | ----------- +Project Group 1 +Project Group 2 -Project Group 3 --Project 1 --Project 2 --Project 3 --Project Group 4 (Maybe..notice it is a sub group) +Project 4 The user can then have multiple working groups or not. They can have multiple projects and groups opened at the same time. They can then build, close, or open a project group. If they do not want to see the files in one group they just minimize the tree. If the groups have a separate context menu "Open Recent Group" then it would make closing and opening groups easier if the user wanted to do that. If the groups tab is a big deal then maybe have the concept of "Main Group" sort of like "Main Project". Then the main group would be the one shown in the group tab. That or allow the user to create a new tab for each group if they would like. In the normal project tab they see the above structure, and have a context menu on the group "Open In Tab". I think it would be nice and productive to allow groups to house other groups as well like the sub-group in the above structure. That way large programs with multiple projects in multiple domains could have more complex and better organized structures. The sub-groups could then work stand-alone if the user only need to work on one of them. Otherwise they can open the entire project group tree. All of that and provide a group context menu and maybe a group menu for operations on groups or the active group: Build Clean and Build Clean etc.... Maybe integrate this with build configurations some how. Have group configurations which allow choosing different configurations from sub-projects and/or different targets. That way the user can define a build configuration and have a context menu for which one to build. That way if they have NB platform projects, regular projects, and web applications they need different deployments and distribution formats for this makes it easy for these things to happen. As far as groups only relevant to the user. The user could always create their own group files and store them where ever they would like. This way groups can become integrated with the build process and project, or they can simply be for use by a single user for grouping purposes.
First impression was not so good since I was used to Tim's one. But after few whiles I got it. Works quite nicely. Just one minor UI improvement. It would be nice if the currently active group is displayed in the "Projects" tab (probably not easily possible currently - no API?). E.g. instead of just "Projects" there would be e.g. "Projects (APISupport group)". Otherwise it is easy to forget the selected group and thus "misconfigure" it.
mk2> is it a feature or bug that the files opened in the editor area are not affected at all by changing groups? I would rather suppose that after group is changed the files associated with project in old group are closed as it is the case with "Close Project" action. The same with "Open Project" action vs. change group case.
mk2> I'm just going through issues I missed and see the comment in 59041 which answered my question.
Here is a user opinion on accessing/switching project groups. UI would be better grouped if the switching between projects is part of the Project Node(explorer view) as a command bar instead of File menu. Please find the screen image attachment from JBuilder for a visual reference.
Created attachment 35570 [details] Accessing project group in Jbuilder
> .....Project Node(explorer view) as a command bar instead of File menu. I would say rather "alternatively to" instead of "instead of" in the above sentence. Simple keyboard access is a must-have for me :) And current "Alt-f, u" is just perfect for me.
>Here is a user opinion on accessing/switching project groups. UI would be better >grouped if the switching between projects is part of the Project Node(explorer >view) as a command bar instead of File menu. Please find the screen image >attachment from JBuilder for a visual reference. I think that might limit the ability to quickly work on multiple projects very easily. I usually work on two or three separate groups at a time myself. So for a use case/reference: I'm talking about completely unrelated projects yet for the same client and sometimes different. I might have an email out I'm waiting for a reply to work on another system and move forward, so I'll work on others as that is going on, and it may be unknown how long it will take to get back on the other project....seconds, minutes, hours, and "personally" I don't like the way it would wait to close windows for other projects and open them for others. The way it works now at least with only projects not groups one can keep both windows open in the IDE and switch between them as needed (editor windows that is). Please note the uses of hide and close in different contexts. It would seem if I really only wanted to work on a project one at a time then maybe use the same concept, but it is for opening recent projects and groups. So you have the same screen you show, but can have multiple groups and projects showing in the explorer. If you hit the drop down and click a group or project it opens the project or group. Then I suppose if you did that you could have a setting: Close other projects and groups when opening project or group so then it would operate like JBuilder in that sense and could be turned on or off in the IDE options. That or the option is "Hide other projects and groups when switching project or group" then projects are never closed unless explicitly chosen to close project from a context menu or other menu, and it is just hidden. Then a tab for open projects would be needed sort of like the groups tab. That would make it easier to select multiple open projects/groups and close them without having to visit every one of them to do so. Then the drop down like JBuilder is incorperated for fast opening and switching. It shows first currently open projects and then under a separator shows a fixed number of recently opened with a more option to see all recent projects/groups up to a modifiable number. The same more option could be seen below the currently open projects/groups. I would think one of those options would be the alternative however. The default working would be to show all open projects and groups in the current Projects view. That would give the user the ability to just collapse or expand groups if they need more space. Maybe at most they would have 3 or 4 open at a time. However the default would do one of these things with editor files: not hide the files in the editor as would be the case with the hide or close option turned on or hide the files for all but the active project in the editor (active meaning the one with it's file being opened from the explorer Projects view). For the first case it could give context options on groups/projects: "Close windows for group/project" "Close windows for other groups/projects" Those are a couple of my opinions/ideas on it. I like the way JBuilder does it sort of like a modified version of C++ Builders concepts. I just think it could be even better with a little more flexibility.
I've seen the talk about the different project groups, but from questions on the nbusers list I think the Eclipse users switching or trying NB will like to have the folder option available for projects and libraries. I may be wrong here, but some questions about adding dependencies and projects to projects makes me think that....I'm not an Eclipse user, so I do not know for sure, but I am on nbusers often. I know I have a couple of projects I would do the same thing for. I have a huge project I keep all these different projects under, so in that case just to be able to add the folder would make sense for me instead of having to open them all and then add them to a free group. There are other times the free group would make sense. Other times the Master project group would help out a lot. I have different projects and scenarios where I would use all three. I would still like to have groups stored in a file or project folder though. Most times in other IDEs I've used and other users per their comments they integrate groups with their build process. It just makes it easier to have a file you check out with the sources and it builds separate yet connected projects. Sometimes you'll have multiple groups you do this with for different release scenarios. Sort of like project configurations except at a higher level and kept up with different groups. You then get the added benefit of being able to more easily visually manage these groups of projects in the file/explorer/project view. It seems we have the facilities to keep this information in a project folder already as we have the ability to add new project types. We could change the File->New Project menu to File->New Group/Project, or for that matter have File->New Project and File->New Group and maybe hide group templates from the project templates on that action and hide the project templates on new group.
Lots of comments! I should preface the following responses by emphasizing that the intended scope of this feature is not very large - it is mainly intended as a convenience. In http://projects.netbeans.org/buildsys/design.html#portfolios this is described as "open project list", plus (if accepted) "VCS project group" for folder groups and "master project" for master project groups. There is no intended implementation of "aggregate project" or (beyond the open project list) "scope for refactoring". Re. turning on advanced features by default to get more feedback - perhaps, during an "experimental" period when logging is collected. TBD. Re. building all projects in a group - Tim tried this in the poorMansPortfolios module. Did not work there for technical reasons (missing API, filed separately). Could be considered as a feature enhancement for the future if it turns out to be widely requested. One problem is that many project types already build their subprojects by default, so a group would need to have privileged knowledge about which projects in the group would already build other projects in the group, so as to avoid asking them to be built twice. More generally, sharing of group definitions and the related issue of integrating groups with build process is really the proper territory of project types. Some project types already do this sort of thing, but it depends on the application domain. You can set up a freeform project to "depend on" any number of other projects and perhaps build them in sequence, but this is up to you - as it probably should be, since I bet that in such circumstances you usually need to do some special build steps anyway to package everything up together. Where the IDE "knows about" a particular technology domain and its aggregation system (e.g. Java EE's EARs), it already sets up this kind of system for you. The project group feature is not intended to address this area at all. Re. displaying nested groups - possible but probably overkill for most users. For many cases you can probably already get equivalent behavior by just setting up sensible project dependencies and creating master project groups. Re. displaying current group name in Projects tab - not possible when implemented as a separate module. If this functionality is simply moved in the existing projectui module (which it probably would be if approved), then no problem. Re. combo box to switch current group in Projects toolbar - easy to do but takes up vertical space. If there were already a toolbar in the Projects tab, would make sense to add this combo to it. Otherwise, prefer not to add a toolbar just for this (especially as it could annoy people who do not care about groups at all), but second opinions requested. Note that you can also switch group from the context menu in the blank area of the Projects tab, if you find this (not as discoverable). Re. working on different groups at once - I hope switching groups can be made fast enough to not be an annoyance, but if not you can always keep several groups open. Or just ignore the groups feature temporarily and open projects you want explicitly. Note that non-autosynch free groups (Advanced Mode only) let you have a stable group definition but still open an unrelated project momentarily to do some quick fix e.g. in response to a mail message. The intention is that the group represents what you are mainly concentrating on at the moment. Tim's module does allow you to look at multiple groups at once, since it has a dedicated tab for this purpose. This can occasionally be useful, but I am betting that the UI complexity outweighs its usefulness overall. Permitting multiple "active" groups would also break or complicate the autosynch mode for free groups.
>One problem is that many project types already build their subprojects by >default, so a group would need to have privileged knowledge about which projects >in the group would already build other projects in the group, so as to avoid >asking them to be built twice. I think I run into this now with projects also. I have projects which depend on the same projects then these projects get aggregated into other projects which other projects depend on. Seems to take a long time running through the ANT scripts as I keep seeing... compile: jar: dist: over and over many more times than the number of projects I have. It would be nice if we had dirty hashes or codes (properties maybe something as simple as dirty.dist=Y, dirty.compile=Y...which could be set on edit and save or something)...basically something to check with a quick load and exit the ANT scripts if they are not dirty. Clean would obviously reset these as well. It might add an issue to checking out then building, but I suppose a quick check for the dist and build folders would tell whether the files needed to be built or not...if the user didn't just get just the updated project files and not the source, but then I would they have other problems anyways. On the other comments I hear you on the scope. The thing about not at least making groups persistent to a file, I think anyways, is that if I am used to managing my projects one way. I then have to help my buddy in a cubical on the same project. We have different groups setup. It would be a little confusing every now and then and would have to remember to go to the projects tab. Most times I've worked with groups in a system sense not social. Someone involved with development would set these up whether it me or someone else. Then everyone would use the same groups. So, that is my thought there: to allow users to save/persist groups in files or just as properties in the project (if a master project) even if they have nothing to do necessarily with the build process. I suppose this is just my perspective, but I tend to not use things to work on a project which I can't actually persist as part of the project. Sometimes when working on a project you use two machines. One you have at a client place and another your personal. You check some things out and in to go between instead of taking your computer in or theirs out. It would be nice to only setup groups once on any given project and then to update them once. Other times it is a communication issue with novices or people new to a project just to keep communication consistent. Things like open group so and so then go to project blank see file then see project blank and see file. You instead have to remember to always tell them to go to project so and so and open it, not the biggest issue, but just a tiny pain. I like the groups idea though.
Re. building - off-topic but see issue #42683. Re. persistence of group definitions - unnecessary for master project and folder groups; could be used for non-autosynch free groups; not a good idea for autosynch free groups since it is likely to result in VCS merge conflicts. Given the extra complexity, prefer not to implement for non-autosynch free groups, though could be revisited in the future.
Removing project group from properties action is strange for me - couldn't find it.
Originally had separate Remove "..." Group action in submenu, but moved this to button in dialog when Jano suggested creating a properties dialog for the group. Could be moved back to a submenu item if there is agreement that this is preferable.
I also vote to move it into a seperate menu item. Since deleting anything in anything's properties seems just strange/hard_to_find/nonintuitive (to me).
- I am not comfortable with the idea of basic and advanced modes, at least in terms of presenting them directly to the user via something like a menu item. These seem more like a choice when creating a group, so why not instead use a toggle in the Create New Group dialog (when the user hits the toggle, he's presented with more or fewer options)? The user shouldn't need to check a box in one place just to customize a feature in another place. - Groups should definitely stay away from any sort of build dependency determination--it's way too easy to screw up complex builds. For example, the composite application project in Enterprise Pack has to do some interesting things during a build, and it would not be easy to externalize that information. This seems like much less of an issue if groups are not presented directly in the project view and are just invisible sets of projects that are opened as a unit (i.e. there's no node on which to put a "Build" action for the group). - I'm not really clear on the value of the autosynch feature. It requires a lot of explanation to the user for what seems like a dubious feature. I think the whole story could be simplified by removing the autosynch feature, and just give the user the ability to snapshot the current set of projects to the current group, or to a new group. As a user, I really don't care about the subtlety of marking a group as tracking what projects I open, especially for then switching between that group and others. I would quickly lose track of which groups are autosynching and which aren't, much less why. Can you give an example use case where autosynch *on a named group* would be helpful? The use case that autosynch seems to be trying to address is in the shutting down of the IDE and restarting, in which the user would like to see the last set of projects he had open previously. However, does solving this use case require inventing a new group kind and pushing those kinds of decisions onto the user? As a user, I don't care about giving the "last session" group a name. As an analogy, I use a plugin called SessionSaver in Firefox, and it has the ability to snapshot the current set of pages and give them a name, or when I open up the browser after a restart, it restores the last session. It has a special session, called "--", that represents the session from the last shutdown. If autosynch is trying to solve this use case, then perhaps a similar approach would simplify things. - How are dependencies for master projects determined? IIRC, there is no standard approach to defining project dependencies, though there is one implementation in the Java project infrastructure. For example, if I have a composite application project with dependencies on BPEL projects, XSLT service projects, Java EE projects, etc., how will the group system know these are dependent? Are you proposing a standard approach for this? If not, and this would only work with Java projects, for example, then I think that's a showstopper for the master project group concept. - Have you given any thought to using groups to hide projects from the view, even though they are still open in the IDE? For example, for master projects, I think it will be critical to be able to hide projects from the full list of recursive dependencies (when it comes to opening all dependencies, the thing I want to do first is hide some of them, especially in NB's flat project list). Without this, I feel like master projects will be much less useful than they should be because they will tend to overwhelm users. Imagine opening a highly-connected NetBeans module... By the way, persisting a list of hidden projects may be justification for persistence of the group information in the project. - I agree with Wade that groups being something outside of the sharable information set for projects makes the feature less useful. In team environments, this is a drawback, and I'm sure that some of the first questions or RFEs received about groups would be about sharing them. Furthermore, I know I'd hardly ever use groups if there were no way to easily persist that information between user directories. Has the idea of a special group project type been considered instead (I'm certain it has, but why was that option rejected)? - An alternate proposal for groups that would eliminate the shareability issue, but result in a drastically different design: The Module Manager uses a simple category name in the module manifest to group modules into categories. This works quite well to reduce the complexity of the module view. Could we use a similar approach for projects by persisting names of groups a project is associated with into each project? This would allow the user to group projects into subtrees of the main project view and thus reduce visual complexity, though it would require users to manually open projects in order to see them (unless they are automatically opened by virtue of project dependencies). This would solve 90% of my personal use cases for groups, as I usually don't care how many projects I have open at a time except for how it affects my project list view.
Agreed. Removing the group should be a menu item. BTW, the properties dialog should have a Cancel button.
1.8 addresses the Remove and Cancel requests.
Moving to projects/projectui module with the following changes: - different preferences node - displays active group title in Projects tab - stores URLs rather than dirs, so non-file-based projects can be supported - shows "(experimental)" in Advanced Mode menu item - does not disable radio button menu items except in advanced mode RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/SubprojectsGroup.java,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/SubprojectsGroup.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/SubprojectsGroup.java,v <-- SubprojectsGroup.java initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/AdHocGroupEditPanelBasic.form,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/AdHocGroupEditPanelBasic.form; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/AdHocGroupEditPanelBasic.form,v <-- AdHocGroupEditPanelBasic.form initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/DirectoryGroupEditPanel.form,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/DirectoryGroupEditPanel.form; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/DirectoryGroupEditPanel.form,v <-- DirectoryGroupEditPanel.form initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/DirectoryGroup.java,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/DirectoryGroup.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/DirectoryGroup.java,v <-- DirectoryGroup.java initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/NewGroupPanel.form,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/NewGroupPanel.form; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/NewGroupPanel.form,v <-- NewGroupPanel.form initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/Bundle.properties,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/Bundle.properties; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/Bundle.properties,v <-- Bundle.properties initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/DirectoryGroupEditPanel.java,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/DirectoryGroupEditPanel.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/DirectoryGroupEditPanel.java,v <-- DirectoryGroupEditPanel.java initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/AbstractNewGroupPanel.java,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/AbstractNewGroupPanel.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/AbstractNewGroupPanel.java,v <-- AbstractNewGroupPanel.java initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/NewGroupPanelBasic.java,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/NewGroupPanelBasic.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/NewGroupPanelBasic.java,v <-- NewGroupPanelBasic.java initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/AdHocGroup.java,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/AdHocGroup.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/AdHocGroup.java,v <-- AdHocGroup.java initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/SubprojectsGroupEditPanel.java,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/SubprojectsGroupEditPanel.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/SubprojectsGroupEditPanel.java,v <-- SubprojectsGroupEditPanel.java initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/Group.java,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/Group.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/Group.java,v <-- Group.java initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/GroupEditPanel.java,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/GroupEditPanel.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/GroupEditPanel.java,v <-- GroupEditPanel.java initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/AdHocGroupEditPanel.form,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/AdHocGroupEditPanel.form; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/AdHocGroupEditPanel.form,v <-- AdHocGroupEditPanel.form initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/GroupsMenu.java,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/GroupsMenu.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/GroupsMenu.java,v <-- GroupsMenu.java initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/AdHocGroupEditPanelBasic.java,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/AdHocGroupEditPanelBasic.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/AdHocGroupEditPanelBasic.java,v <-- AdHocGroupEditPanelBasic.java initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/NewGroupPanelBasic.form,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/NewGroupPanelBasic.form; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/NewGroupPanelBasic.form,v <-- NewGroupPanelBasic.form initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/NewGroupPanel.java,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/NewGroupPanel.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/NewGroupPanel.java,v <-- NewGroupPanel.java initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/AdHocGroupEditPanel.java,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/AdHocGroupEditPanel.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/AdHocGroupEditPanel.java,v <-- AdHocGroupEditPanel.java initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/SubprojectsGroupEditPanel.form,v done Checking in projects/projectui/src/org/netbeans/modules/project/ui/groups/SubprojectsGroupEditPanel.form; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/groups/SubprojectsGroupEditPanel.form,v <-- SubprojectsGroupEditPanel.form initial revision: 1.1 done Checking in projects/projectui/arch.xml; /shared/data/ccvs/repository/projects/projectui/arch.xml,v <-- arch.xml new revision: 1.18; previous revision: 1.17 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/DirectoryGroupEditPanel.java; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/DirectoryGroupEditPanel.java,v <-- DirectoryGroupEditPanel.java new revision: delete; previous revision: 1.1 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/NewGroupPanel.form; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/NewGroupPanel.form,v <-- NewGroupPanel.form new revision: delete; previous revision: 1.6 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/AdHocGroupEditPanel.java; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/AdHocGroupEditPanel.java,v <-- AdHocGroupEditPanel.java new revision: delete; previous revision: 1.3 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/DirectoryGroupEditPanel.form; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/DirectoryGroupEditPanel.form,v <-- DirectoryGroupEditPanel.form new revision: delete; previous revision: 1.1 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/AdHocGroup.java; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/AdHocGroup.java,v <-- AdHocGroup.java new revision: delete; previous revision: 1.5 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/AbstractNewGroupPanel.java; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/AbstractNewGroupPanel.java,v <-- AbstractNewGroupPanel.java new revision: delete; previous revision: 1.1 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/SubprojectsGroupEditPanel.form; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/SubprojectsGroupEditPanel.form,v <-- SubprojectsGroupEditPanel.form new revision: delete; previous revision: 1.1 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/AdHocGroupEditPanelBasic.java; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/AdHocGroupEditPanelBasic.java,v <-- AdHocGroupEditPanelBasic.java new revision: delete; previous revision: 1.1 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/Group.java; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/Group.java,v <-- Group.java new revision: delete; previous revision: 1.9 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/DirectoryGroup.java; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/DirectoryGroup.java,v <-- DirectoryGroup.java new revision: delete; previous revision: 1.1 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/GroupsMenu.java; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/GroupsMenu.java,v <-- GroupsMenu.java new revision: delete; previous revision: 1.8 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/AdHocGroupEditPanel.form; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/AdHocGroupEditPanel.form,v <-- AdHocGroupEditPanel.form new revision: delete; previous revision: 1.1 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/AdHocGroupEditPanelBasic.form; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/AdHocGroupEditPanelBasic.form,v <-- AdHocGroupEditPanelBasic.form new revision: delete; previous revision: 1.1 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/layer.xml; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/layer.xml,v <-- layer.xml new revision: delete; previous revision: 1.2 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/NewGroupPanelBasic.form; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/NewGroupPanelBasic.form,v <-- NewGroupPanelBasic.form new revision: delete; previous revision: 1.1 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/SubprojectsGroupEditPanel.java; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/SubprojectsGroupEditPanel.java,v <-- SubprojectsGroupEditPanel.java new revision: delete; previous revision: 1.1 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/SubprojectsGroup.java; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/SubprojectsGroup.java,v <-- SubprojectsGroup.java new revision: delete; previous revision: 1.1 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/NewGroupPanelBasic.java; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/NewGroupPanelBasic.java,v <-- NewGroupPanelBasic.java new revision: delete; previous revision: 1.1 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/Bundle.properties; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/Bundle.properties,v <-- Bundle.properties new revision: delete; previous revision: 1.7 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/GroupEditPanel.java; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/GroupEditPanel.java,v <-- GroupEditPanel.java new revision: delete; previous revision: 1.1 done Removing contrib/projectgroups/src/org/netbeans/modules/projectgroups/NewGroupPanel.java; /shared/data/ccvs/repository/contrib/projectgroups/src/org/netbeans/modules/projectgroups/NewGroupPanel.java,v <-- NewGroupPanel.java new revision: delete; previous revision: 1.8 done Checking in nbbuild/build.properties; /shared/data/ccvs/repository/nbbuild/build.properties,v <-- build.properties new revision: 1.426; previous revision: 1.425 done Checking in projects/projectui/nbproject/project.xml; /shared/data/ccvs/repository/projects/projectui/nbproject/project.xml,v <-- project.xml new revision: 1.32; previous revision: 1.31 done Checking in projects/projectui/nbproject/project.properties; /shared/data/ccvs/repository/projects/projectui/nbproject/project.properties,v <-- project.properties new revision: 1.17; previous revision: 1.16 done Checking in projects/projectui/src/org/netbeans/modules/project/ui/ProjectTab.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/ProjectTab.java,v <-- ProjectTab.java new revision: 1.34; previous revision: 1.33 done Checking in projects/projectui/src/org/netbeans/modules/project/ui/OpenProjectListSettings.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/OpenProjectListSettings.java,v <-- OpenProjectListSettings.java new revision: 1.25; previous revision: 1.24 done Checking in projects/projectui/src/org/netbeans/modules/project/ui/Bundle.properties; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/Bundle.properties,v <-- Bundle.properties new revision: 1.83; previous revision: 1.82 done Removing contrib/projectgroups/nbproject/project.properties; /shared/data/ccvs/repository/contrib/projectgroups/nbproject/project.properties,v <-- project.properties new revision: delete; previous revision: 1.1 done Removing contrib/projectgroups/nbproject/project.xml; /shared/data/ccvs/repository/contrib/projectgroups/nbproject/project.xml,v <-- project.xml new revision: delete; previous revision: 1.1 done Checking in projects/projectui/src/org/netbeans/modules/project/ui/resources/layer.xml; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/resources/layer.xml,v <-- layer.xml new revision: 1.72; previous revision: 1.71 done Checking in ide/golden/deps.txt; /shared/data/ccvs/repository/ide/golden/deps.txt,v <-- deps.txt new revision: 1.375; previous revision: 1.374 done Removing contrib/projectgroups/manifest.mf; /shared/data/ccvs/repository/contrib/projectgroups/manifest.mf,v <-- manifest.mf new revision: delete; previous revision: 1.9 done Removing contrib/projectgroups/build.xml; /shared/data/ccvs/repository/contrib/projectgroups/build.xml,v <-- build.xml new revision: delete; previous revision: 1.1 done
Even though the issue's been closed i'm going to add my opinions :-) since i've used the contrib/poorMansPortfolios alot. I feel that my behavior follows Wade's closely. I need a way to quickly open additional projects without actually adding them to the group. ("Automatically Track Open Projects" solves this). I need a way to quickly change between groups. Or to be able to select multiple groups at one time. (I mean quickly, the current switch of open projects takes some time). Otherwise the new implementation is superb! Nicely done Jesse :-) Indeed netbeans is faster for me now because i don't have 100+ projects open in different groups, but just the projects open for the current group (groups hopefully soon ;-)
I checkout the source code for poorMansPortfolios project groups and make a little changes to make it build and work for netbeans 6.0. If you like the poorMansPortfolios implementation as I do you can download it http://blogs.sun.com/wind/resource/projectgroups/org-netbeans-modules-project-portfolios.nbm and http://blogs.sun.com/wind/resource/projectgroups/org.netbeans.modules.project.portfolios_071216-163102.zip is the source code.
Windii - feel free to check your changes into contrib/ if you like - or email me a patch.
Created attachment 54313 [details] patch to make poorMansPortfolios build in netbeans 6