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.
Using relative ordering attributes has proven to be cumbersome when the number of modules contributing to a folder is large. It should be possible to use numeric ordering as a simpler alternative.
Do you know that /etc/init.d scripts deprecated numeric ordering and are switching to relative one?
I had not heard that. (Reference? Google turns up nothing.) Nonetheless the justification listed in the wiki still applies.
http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/deliverable1/debianboot_d1.pdf
Interesting, but a quite different situation with little bearing on NB.
Dafe will be interested in this too, as he had to reorder Windows menu for M9. And was not lucky about that, surprisingly...
Great! I spent many evenings with relative ordering and proposed change will make our developer life (and life of our customers) much easier, I fully support proposed solution. Thanks for this...
*** Issue 24776 has been marked as a duplicate of this issue. ***
A thing which is still not fully clear to me is whether this is proposing an incompatible change or not. If it is, then I'd like to remove the FAST from API_REVIEW_FAST, if there was such keyword. Anyway, I'd like to see a discussion about possible options before doing an incompatible change.
I don't expect any incompatibilities. As detailed in the wiki, relative ordering attributes would continue to function, after logging warnings. It's not up for API review yet because I am still developing it. But you can see the plans on the wiki.
I would like to submit this change for API review, targeted for inclusion in M10. Everything you need to know is in the wiki. I am continuing to work on implementation (mainly usages of the new API) but the API itself, including usage in DataFolder, should be ready for review. I expect changes to be compatible - while I will upgrade all modules in the standard IDE, unmodified third-party modules should still be able to insert files in relative positions (with warnings printed to the log).
I support a module unchanged between NB55 and NB60 (thanks to a little reflection). One problem was the position of a Tools menu item. Discovering that position was determined through a tsort algorithm actually made is simple to set it up so the same layer file worked with both NB versions. The wiki seems to indicate that good practice, when changes are made, is to keep existing numbers as possible. There's a question in here somewhere... How difficult do you think it will be moving from release to release with the absolute verses relative schemes?
To err's question: If the immediate context of your menu item does not change between releases, then relative ordering attributes are OK: you can use the same pair of attrs for both releases. The problem arises when the nearby menu items do change. In some cases you can overspecify your order in such a way that your item will still show up in the right place in both releases. (If the menu is totally rearranged this might not be possible, though this is rarer.) This can be pretty cumbersome, however. Using numeric positioning, you would just choose an appropriate position in the earlier release and then check up on it in the newer release. It is possible your menu item will have "drifted" a bit, though catastrophically wrong positions are much less likely than when using relative attrs. You are correct that it is desirable for maintainers of the IDE/platform/whatever to not make gratuitous changes to positions of existing menu items between releases. As mentioned in the wiki, I have a script which I plan to use to replace all relative attrs with numeric positions in the full IDE (i.e. including visualweb, uml, ...). It simply assigns positions 100, 200, 300, ... to each file/subfolder in the desired order. This should be enough to get us started, though probably for 6.0 we will want to hand-tune the positions for important areas like the menu bar and list of templates, so that separators are placed e.g. at multiples of 1000 and perhaps named according to their position ("sep2000.instance").
Created attachment 43839 [details] Log of relative -> position conversion
Created attachment 43840 [details] Commit log
Implemented in trunk. Minor tasks remain, as detailed in wiki.