Community
Participate
Working Groups
I'm fully aware that Java packages *aren't* hierarchical in nature, but in order to find a certain package, it makes things much easier if they can be *displayed* hierarchically. Going through the list of packages in my workspace trying to find the right one takes much longer now than it would with a hierarchical display. I know many people prefer a flat display, and that's fine - I'd only suggest this as an option, and not even a default one at that. Please let those of us who understand the philosophical situation but have practical difficulties with it get round those practical difficulties :) Jon
FYI.
I second this, for both the Java and Java Browsing packages views.
revisit after 2.0
*** Bug 10029 has been marked as a duplicate of this bug. ***
Added "helpwanted" keyword. Nothing planned for 2.1 unless patch/code is provided.
This feature request is similar with what Microsoft has in Visual J++ 6.0 I really believe we need this feature, as it makes your life easier when you have large projects. I'm considering to switch from Visual J++, but this not hierarchical display is one of the reasons I'm not doing it yet.
Added my email address in CC list
Created attachment 2101 [details] Beta patch
I came up with this patch after looking at the package explorer code for a bit. It affects only org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider. Set the fHierarchy field of PackageExplorerContentProvider to true to enable it (needs to be hooked up to a preference or other UI option). It works by wrapping IPackageFragments: the wrapper reporting sub-packages as non-java elements, which in turn are contibuted to the tree. This approach requires minimal changes to the existing code (only one method overridden, and one inner-class), and all existing functionality should be retained because the wrapper behaves as a normal package for all java operations. One known artifact is that refactoring operations on a package will not affect sub-packages (due to the way refactoring works). Also, empty parent packages will not be filtered (ie. the entire hierarchy is shown).
Scott, thanks for your patch. The patch is a good start. The problem with the approach is that it violates API of IPackageFragment which says: * <p> * This interface is not intended to be implemented by clients. * </p> Hence we can not go down this road. Other problems of the patch are: - the resulting content provider does not handle changes to the model. All Java element deltas need to be mapped to this new artifical layout e.g. if you add a package it will not be shown. Deleting a package leads to zombies. - problem markers are not shown for the artifical nodes - code does not work for "projects as source folder" layout - I think label provider also needs to be changed. I would expect to see: + java - io instead of + java - java.io Comments? - introducing a proxy (most often) leads to troubles e.g. if you select a package (type PackageNode) in the Package Explorer the Browsing views will not be able to set the selection because the packages are not equal ==> the equals and hash dance has to be done. It also shows that lots of other areas are affected - label provider - see my comments above - image provider - currently a folder icon is used for a package with only resources. This looks odd when looking at a package tree - sorter - packages with only resources are sorted at the end. This might lead to + java + com if com has a resource - filters * filters are attached to the view. Not all filters might be useful/applicable to both layouts. This one is tricky because plug-in developers can add filters to the Package Explorer. You solved one of this problems (empty package filter) by changing the semantics of hasChildren(). This can have various side effects for those relying on the real semantic and is violating the API spec of IJavaElement.hasChildren(). Given the interest in this PR we also started to experiment with package tree view to get a feeling of the issues.
Thanks for the feedback, Daniel. I have reworked it to not use proxies, and instead do everything directly through the content provider (still only a 1 file fix). I can post the new patch if you like. I agree that the labels should be modified to only display the partial name. This should doable by adding another flag to the JavaElementLabels class, taking care not to compress the name in such a case. Might this affect some label decorators, though? The number of classes needing to know about the hierarchical view seems to indicate that a public flag must be available (eg. through IPackagesViewPart). This way external filters will be able to behave properly in either mode.
*** Bug 24425 has been marked as a duplicate of this bug. ***
Jon, yes please attach the new version. Does the new version now handle resource and Java element changes? Regarding the label: - compression is not a problem since the last segment is never compressed anyway - we have to see if we add a flag to JavaElementLabels - it already has lots - decorators: it depends on the implementation: are packages from different roots mixed together? Example: - have JUnit packages from a JAR (=> read-only and binary) - load source code from CVS with package junit.tests => if both "junit" nodes are folded together there will be problems but if two "junit" nodes appear it should be OK (though looking a bit odd) >The number of classes needing to know about the hierarchical view seems to >indicate that a public flag must be available >(eg. through IPackagesViewPart). This way external filters will be able to >behave properly in either mode. This can't be done via IPackagesViewPart until 3.0 since API must remain as is for 2.1. I guess since the empty packages filters are already provided by JDT we don't need new API. Or do you see another new filter that would really need to test if the package is empty? Suggest to add this for 3.0 if there will be a concrete demand/PR for it.
Sorry - previous answer was of course for Scott.
Working on handling deltas. PackageFragments are still displayed seperately, so there should be no problem there. The API change I suggested only because other plugins CAN contribute their own filters (even if none do currently), and any such filters might need to know about the setting (such as the 'empty parent packages'). For now I'm sure it's not an issue, but I can see it coming up in the future. Work continues...
For M3 this feature will go into the Package Explorer. Still investigating how it can be integrated into the Packages view (not committed for M3).
Released first cut of this feature to HEAD - will be in tonight's nightly build and next Tuesdays integration build. The Package Explorer has a new view menu called "Layout" which allows to switch between "Flat" and "Hierarchical" (default is flat). There is also a preference (Java -> Appearance) which allows to set if empty package fragments are folded together when in hierarchical view (default is true). Please assign bugs you find with this new feature directly to me. Note: Hierarchical layout for Packages view is still under investigation.
Added a new feature for Hierarchical packages in Pacakges view (feature 25583)
