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.
In order to implement properties on nodes we need to know exactly what is the display name and what is the short description (tooltip). Display names are usually clear from the uispec, but the description is missing.
i've added descriptions to the java spec. they follow the property name so you have <prop name> - <description> sometimes there is additional information after the description that is for use in the spec only. the updated spec will be pushed to projects.nb.org later today or tomorrow.
OK, re-assigning to developement. Also I think we should try to implement descriptions for usability study.
Chris, could you review the section Properties - Packages node in Java UI Spec? You specify a property with a weird description there: List of Java Roots -read only.
Updated already implemented properties. Remaining should be implemented according to the java ui spec.
the packages node should have a property for each Java root present. it would look something like: Property: Name: Java Root | c:\path\to\root Java Root | c:\path\to\second\root Java Root | c:\path\to\third\root description: Java Root directory for the project.
The Packages Node' property was already implemented as a read-only list of roots separated with comma some time ago. Are you going to change the spec again? If so, you should update the document and file a new task.
It would be interesting to see several properties with the same name. Not that it could not be done but it is... awkward. Also please note that the "Edit..." operation in Packages node Customizer is essentially a shortcut for remove/add sequence; there's no point in re-defining the pointed to object; as it completely changes the root's contents, having a true "edit" operation would only complicate handling without any user benefit.
Agreed. The properties with the same name look really strange. I have never encountered such a mapping to properties in the IDE yet. Personally I would prefer a possibility to switch between logical/physical (packages/folders) views on the Packages node. The switch could be an item of node's menu or its property. To Edit... button. It is currently implemented as a remove+add shortcut.
I agree with Svata that this would be *ugly*. Sorry, but it seems like a hopeless effort to cover up the real problem which is: The Packages node visualizes sources from one or more source directories. While there are reasons why this makes sense (a coherent view of the contents of source classpath) there are also some problems that this brings (it is not obvious what sources are under which root folder). I think that this problem can and should be solved. If there is only one physical location of sources the current design works just fine and there is also just one value of the property ;-) I think that the case in which the java sources appear in multiple locations does not appear in simple applications. If the user deliberately decides to put sources in multiple locations then there is a good reason for that. Often times this would also mean the the sources are compiled by different compilation units (although they do not need to be). IMO this justifies that we show the files in each physical location in a separate tree. <btw> Do you have list of examples (use cases, user scenarion, ..) which lead to defining multiple locations for sources? </btw> The user may still decide to prefer the coherent view of classpath contents merged together and ignore the physical locations (and then the comma-separated list of locations + showing them in customizer is enough). The choice can be presented in customizer, just like there is a choice of project view in project node customizer.
I experienced a mid-air collision of my comment with Jan's :-) I could have just said +1 and that would have saved some words :-)
Re.: use cases Apart from NetBeans (some modules have libsrc and src dirs, which are compiled at once), I don't have many. I would recommend to use such technique for localication subteam (with locale bundles separated to the other subtree -- it would be nice to see a merge in packages, though. And I saw some other projects where relatively independent subcomponents were developed in their own subtrees (the same situation as in NetBeans, probably), but they were still compiled together. The last situation can be extended to cover various versioning requirements of the team (two or more VCSs ?), whether part of the files do not come from other source (-> changes separated to another phys location), ... Agree that it is far more probable to have 1 jsource root per cc. build target with several such build targets in the project than multiple jsource roots. However the merge was originally introduced to assist the user abstracting from physical locations for sets of jsource roots that are processed together (those compiled by the same b.t). For jsource roots that use different processing, the merge does more harm than it increases productivity, IMO.
ok. leave it as it is.
As described in http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss the current work on projects prototype has been stopped. Marking issue as VERIFIED --->
---> CLOSED