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.
NB200405161800 & JDK 1.4.2 Now, after 1 month playing with NB4.0, it seems that the notion of super-project is missing. I will explain: I work on the NetBeans project. It means that a lot of NetBeans subprojects are mounted (sorry to continue to use that vocabulary for 4.0, I have not yet founded another word therefore). But I am also working for somes others projects. Before, with previous versions of Project, I created one project per project, and I mounted how much filesystems as subproject. Now, I have all projects and subprojects in the same Projects windows. And only one project can be the main. It begins to be not easy to walk through the project structure. I though that solution was to have one nb user directory for each super projects, but then, I have to recreate all my configuration like keyboard shortcuts (I am using a belgian french keyboard, so a lot of keyboard shortcuts are not accessible), modules installed via the Update Center, ... Am I missed something ?
Please get to the point. Is the problem "It begins to be not easy to walk through the project structure"? If so, what exactly is wrong? Projects tab navigation? Ease of opening/closing certain projects or groups of them? Visualization of dependencies? Be concrete - use cases, examples; and limit a given bug report to one clearly defined topic. It should be possible to immediately see whether a bug can be closed as fixed or not just by reading the description, checking in a current dev build, and seeing if the request was implemented or not. Otherwise using an issue-tracking tool is inappropriate. Definitely you are not intended to have multiple user directories, that is out of the question. Also please refer to http://projects.netbeans.org/buildsys/design.html#portfolios for basic terminology.
You want concrete example ? So hereafter some concrete example. At work, they developped their own Framework. That framework is based upon a lot of modules: We have our logging module, our monitoring module, our presentation module, and a lot of other specific modules. When we start development of a new IT Project, we reuse bricks of our framework. All our projects are identified by 3 letters. During development of projects, the framework continued to be developped/enhanced. So, I have a Project ABC based upon our Framework 3.1, I have another Project DEF based upon our Framework 3.2, I have a third project GHI based upon our Framework 3.3 and now, I have a demo project based upon our Framework 4.0 beta. I need to work with all thoses projects in parallel. So, now in the Project Window, I have the following: ABC JFW3.1 logging monitoring dblayer presentationlayer businesslayer DEF JFW3.2 logging monitoring dblayer presentationlayer businesslayer GHI JFW3.3 logging monitoring dblayer presentationlayer businesslayer Demo JFW4.0Béta logging monitoring dblayer presentationlayer businesslayer As you can see, I have more than one subprojects having the same name. So, it's not easy to be sure that I am now working within the subproject monitoring of the project JFW4.0Béta and not of the project JFW3.1 It would be nice for me, if I could have somethink like that: ABC JFW3.1 logging monitoring dblayer presentationlayer businesslayer ---------------- DEF JFW3.2 logging monitoring dblayer presentationlayer businesslayer ----------------- GHI JFW3.3 logging monitoring dblayer presentationlayer businesslayer ----------------- Demo JFW4.0Béta logging monitoring dblayer presentationlayer businesslayer ----------------- And easily fold/unfold|close/unclose those four super-projects P.S. I see only one topic here: have notion of super project.
Re. "So, it's not easy to be sure that I am now working within the subproject monitoring of the project JFW4.0Beta and not of the project JFW3.1" - true, unless you give the subprojects more distinctive names (e.g. "monitoring-jfw31"), which I would certainly recommend. There used to be a tooltip on the project giving its directory location. That's gone; you can use Properties to find the same info now. However it is not convenient to get to when you need to select from among a lot of projects. Perhaps we need to reintroduce some UI which would enable you to quickly distinguish between multiple open projects with the same name. I am not sure how common this scenario really is, however, given that you can choose better project names to begin with. For now I might recommend that you close the projects you are not working on actively and just keep open the ones you want to see at a given time. The "Open Required Projects" checkbox in the Open Project dialog makes this somewhat easier to open a group at once (just select the topmost project) in case all are subprojects of one main project; to close them all, currently you have to multiselect. (We could probably make this easier, though it is not so clear what to do when some subprojects are shared, i.e. the directed acyclic graph of your project dependencies is not a tree.) Then you would see e.g. just: businesslayer dblayer Demo JFW4.0Beta logging monitoring presentationlayer which is hopefully manageable. In a future release we may introduce a UI that would let you explicitly name and open or close a list of projects (given with absolute paths, or relative to the list file), which would probably be displayed together too. This is mentioned in the design doc as an "open project list". TBD whether this would allow multiple open lists; if so, it is unclear how shared subprojects would be handled; if not, it could be very annoying for people who mostly want to work on a fixed set of projects (their normal work) but from time to time also want to do something minor in a different project. The current Projects tab lists all open projects alphabetically. Pros: quick to find a particular project assuming they are named distinctively; relatively flat tree structure uses space efficiently. Cons: no visualization of dependencies; confusing if >1 open project has the same name. Other proposals for Projects tab display have included 1. Nesting subprojects inside the parent project. Pros: easy to see dependencies. Cons: potentially confusing to have subprojects at same level as e.g. "Source Packages"; deep nesting makes navigation slower in many cases and requires a wider Projects tab (bad for laptop users); shared subprojects cannot be displayed sensibly. 2. Sorting projects acc. to a topological sort by dependency. Pros: groups together related projects in most cases; automatically shows main project at the top. Cons: potentially mysterious to the average user where the sort order is coming from; shared subprojects displayed in a location appropriate to only one parent project and not the others. 3. Leave projects unsorted (in last-opened order), possibly with D&D reordering. Pros: groups together related projects in most cases; usually shows main project at the top; uses space efficiently; easier to close a group of related projects. Cons: difficult to find a particular project by name if you have a lot open; behaves oddly with shared subprojects, or generally if a subproject was already open; many users might never discover the reorderability; requires manual intervention to correct the ordering if you did not open projects in any particular order. Different styles work out better or worse for various scenarios; no single solution we have found is ideal for all situations. E.g. a J2EE EAR project will commonly have WAR subprojects, which may in turn have taglib subsubprojects (which may commonly be shared among >1 WAR). Here there would be three different icons representing the different project types. Or e.g. in the case of NB module projects, the nesting would be so deep as to make #1 impractical, and there are a lot of them so #3 would be hard to use. The situation in NB 3.x was probably worse since you would have a list of mounted filesystems, incl. >1 mount per effective project in some cases (esp. for web apps), where the ordering was significant to compile and execute semantics (making it impossible to have >1 VCS branch of the same app open and runnable at once without reordering the mounts manually), and no mnemonic display names for the individual mounts. The pro of the NB 3.x UI was probably that the mount root nodes in Filesystems displayed the full folder path (just for directories - not for JARs, curiously), making it easier to identify a particular version of something. Leaving open for Jano to comment on further, though at this point I don't expect to find a clearly superior solution for D. Of course these things are open to reevaluation, esp. after we have more experience in the field; would not require a lot of work to implement alternative proposals, I think. The problem is not finding some UI that would handle a particular use case well, it is selecting a single UI that is at least adequate for all commonly encountered use cases. Unfortunately usability studies don't help much in this area since you can't ask someone in a lab to work on twelve applications under version control over the course of some months in a team of five developers etc., which is the point at which we could see the real impact of different approaches.
This issue of NetBeans providing project grouping relates to me very strongly. I have a presumptious view that I think I understand the resistance NetBeans developers have in providing this feature. Firstly, introducing a wildly presumptious and speculative or even unkind statement, is the "let's not be too JBuilder" mode of thinking. Which I hope is not the case. Secondly, as someone providing services to groups of people, I also tend to like people to perform projects in the way I perform them. If I could do it that way, why can't those guys do it that way too. With all the apologies in place about both my above statements, I wish to urge NetBeans developers to turn around and see the mode of operation for us in the business and manufacturing industries. We have probabably KIV (keep-in-view) about 7 to 10 active production projects at any moment of our programming lives in the office plus another 5 experimental projects. Of the 7 or 10 active projects, we would have about 3 we would be concurrently working on. Let's look at the following scenario. I am working on a Cpk project projected to complete 1 May. I had a product costing project I completed 1 Jan. I am just told that I need to start immediately on a menu driven front-end which would just take me two days. I also have 5 other projects in kept in view. I also have 5 experimental projects where I try out various features of J2EE, JDK1.5, JFree, Sitraka & SAS respectively. I am working on this Cpk project, and then suddenly I see this group of engineering managers standing behind me with an accountant. OK, I am pressured to revive the product costing project with all these big shots (or perhaps, big shorts) milling around me. I fumble around, close some projects, open some. I have a few libraries involved, each encapped in their own project. All I wanted to do is to bring up the application, show it to them, tweak a little in the few classes in other projects. But they have been standing around for the past 7 (seems like my favourite number) minutes embarassing my boss for my ineptitude (or is it spelt inaptitude?) to even bringing up this simple project. Only if I had project grouping in NetBeans. You know, the wonderful NetBeans feature where we could park our Files, Runtime, Navigator(what does this window do anyway?), Output, HTTP Monitor, etc, windows. We could also park the Project:Cpk, Project:MyTaglibs, Project:ProdCost, Project:J2Experiments, etc. Then my boss' face wouldn't be so red now. Hrrmphhh ....! He must be thinking about the asset acquisition I should have proposed to buy JBUilder, which is too late into the financial year now. I guess I could write a novel and get the booker prize (does dual citizenship qualify for booker?) for it, but I hope you all get the picture.
While some programmers turn to pinball or FreeCell when a project gets too frustrating, I would like to abruptly turn to and play around with my favourite experimental project group without having to fumble around trying to recall which projects are involved. Perhaps, in the midst of a working on one project, I find I cannot recall how one of my classes work. So, I turn to my JDK Experiments project, which requires 3 other projects. Now my projects are all cluttered. I can't recall which ones to close. I waste a few minutes to close all unneeded projects. Two minutes later I found I have to perform another experiment. Waste a few minutes to open my experiments and then another few minutes to close them.
I have increased prio to P1 to at least start some discussion about this topic. I personally see this as big drawback of our project infrastructure. I know that I'm not typical developer - I'm QE guy, but ... if I use couple of project groups (I mean projects that are dependent on each other or somehow related) it's frustrating to set up the environment for me. Some example: I open some netbeans project to look into source code, the project has 15 dependent project, but I want to se only 3 of them, so *I close 12* of them and do something. (Doesn't have to be netbeans project!!!) Then I need to try something out with 1.5 with some libraries and other dep. projects and I don't need to have the netbeans project opened at all - it's just dispersing - so I would close it but I cannot because of the tedious setup that I had to do - the result is that I have number of useless projects opened, Explorer and Editor full of projects and files that I don't need. The problem would be solved by having some simple way of logically grouping projects and being able to close/open such group.
This is to some extent fixed by project groups (see File>Project Groups) and by allowing you to have no main project (in that case, all actions are context sensitive). Marking as WONTFIX, noting that the issue was fixed in a bit other way.
Status changed to -> WONTFIX