Community
Participate
Working Groups
Build ID: I20070625-1500 T entries in the Referenced libraries node in the package explorer are displayed in the order they are defined in the .classpath file. While this may be OK in some cases, I often have a hard time finding something in the lists of depencencies. It would be much easier to have them sorted alphabetically.
Created attachment 95585 [details] JavaElementComparator with a "QuickFix" The sorting seems to be broken. JavaElementComparator seems to not make no distinction for JarPackageFragmentRoot (which compromise Referenced Libraries), hence it handles them in the same way it handles other PackageFragmentRoot(s) which require different sorting algorithm. Attached is a "QuickFix" for compare method. Hopefully someone can implement a proper fix: if(e1 instanceof JarPackageFragmentRoot && e2 instanceof JarPackageFragmentRoot){ return ((JarPackageFragmentRoot)e1).getElementName().compareTo( ((JarPackageFragmentRoot)e2).getElementName()); }
We need to add this as an option (for example in the view menu). There are users that want to see the classpath order, we can't break them.
Of course making it configurable would be even better! As soon as I can find a free time slot (those are definitely too rare...) I will try to come with a patch.
*** Bug 213739 has been marked as a duplicate of this bug. ***
*** Bug 361236 has been marked as a duplicate of this bug. ***
This is necessary in the following situation. Let's say you are using Maven and m2e and have included your server runtime as a "Provided Dependency". this creates a Maven Dependencies pseudo-folder in Eclipse. Oftentimes you may wish to look inside one of these jars. Perhaps to look at some xml configuration file that is stored there as part of the runtime, or perhaps to take avantage of Maven's handy source code retrieval features. But this happy scenario is less happy when you have to scan through three or four pages of unsorted jar files just to find the one you want.
*** Bug 396589 has been marked as a duplicate of this bug. ***
For the time being, the "dependency hierarchy" tab of the POM editor (of m2e) allows sorting alphabetically.
*** Bug 428767 has been marked as a duplicate of this bug. ***
*** Bug 440964 has been marked as a duplicate of this bug. ***
Any chance of this being fixed. It is one of the biggest reasons I avoid fulling integrating with Maven. The library list is completely useless to a human.
c'mon guys is nobody out there who can fix this? i can't be that much work that nobody in more than 8 years couldn't fix it
Making dependency list sorted is very reasonable, at least much better than leaving it unsorted. Waiting for this improvement for years...
*** Bug 518531 has been marked as a duplicate of this bug. ***
Created attachment 270333 [details] Screenshot: Preference Page New Gerrit change created: https://git.eclipse.org/r/105666 This will add a preference to the "Java / Appearance" page which toggles the behavior.
Created attachment 270334 [details] Screenshot: sorting enabled This screenshot shows the effect after enabling the option. The effect becomes already visible when pressing "Apply" on the preference page.
Thanks for the patch, Karsten. Please find below the review comments: - The patch sorts the roots also which should not be done as it mixes up the library roots and source folder roots after sorting. Only the entries within the library roots should be sorted. - The preference should specify the places where it is applicable if it is not reflected everywhere in the UI (e.g. it isn't reflected in the Java Build Path dialog > Libraries tab). In that case, the preference option should be "Sort library entries &alphabetically in Package Explorer". - Found one issue: If we open the Project Explorer view when the preference is enabled, the entries in Project Explorer are also sorted. But changing the preference when the Project Explorer view is already open doesn't reflect anything in Project Explorer. Please check this inconsistency for Project Explorer and other such locations where this comparator will be used. The preference should be named accordingly. - Update the Javadoc of JavaElementComparator. - Update the F1 help documentation with the new preference option describing where it is applicable and what is actually sorted or not sorted.
Thanks for the detailed review. I'll try to address your findings when having some time.
*** Bug 531604 has been marked as a duplicate of this bug. ***
> - Found one issue: If we open the Project Explorer view when the preference > is enabled, the entries in Project Explorer are also sorted. But changing > the preference when the Project Explorer view is already open doesn't > reflect anything in Project Explorer. Please check this inconsistency for > Project Explorer and other such locations where this comparator will be > used. The preference should be named accordingly. Had a look at this one and did not find a solution. The problem is that the sorting is done here by JavaElementSorter, and it is not aware of preference changes. While we could add itself as a listener, it could not remove itself again. This again could be worked around by an executable extension factory, making this heavier. Even worse, after a change the common navigator tree would have to refresh, and the JavaElementSorter has no access to the tree. Therefore I tend to restrict this feature to the Package Explorer for now. If someone has an idea how to extend this to a commonSorter of the navigator, please leave a note here.
Does this involve any API change ? Noopur is on vacation and can look at it in M7.
I have just pushed my current state. In that version it involves a new constructor for JavaElementComparator. Could you please give me a hint where the sources for F1 help docs are? I assume it has to be added for the Appearance page, but where do I find the docs? The other issues should not be addressed.
F1 docs are in the repo eclipse.platform.common /org.eclipse.jdt.doc.isv /org.eclipse.jdt.doc.user
New Gerrit change created: https://git.eclipse.org/r/118333
Gerrit change https://git.eclipse.org/r/105666 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=eb6cb66905acd144d5164496839292915c7d7a92
Please add N&N entry.
Thanks a lot! Will provide an entry.
New Gerrit change created: https://git.eclipse.org/r/118526
I just tried this and found that the functionality did not work when working sets are top-level. I just submitted a patch for that.
(In reply to Karsten Thoms from comment #29) > I just tried this and found that the functionality did not work when working > sets are top-level. I just submitted a patch for that. What do you mean by Working sets are top-level? Steps or screenshot will help to understand.
Created attachment 272982 [details] Screenshot The WorkingSetAwareJavaElementSorter is used when the Package Explorer is configured to show Working Sets as root elememts from the view menu.
Gerrit change https://git.eclipse.org/r/118526 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=713a22b1418066e46e922a0b6af249f5fac640d1
New Gerrit change created: https://git.eclipse.org/r/118644
Gerrit change https://git.eclipse.org/r/118333 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=93eff37a8c9c116e1214c96f94cdcbbac2af2def
Thanks Karsten!!
Thanks for your review!
We need an entry in N&N for this item.
Gerrit change https://git.eclipse.org/r/118644 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=abaec5b285492de1abb13f9e738e73924ab7212f
There was already one prepared: https://git.eclipse.org/r/#/c/118644/ Merged that now.
(In reply to Karsten Thoms from comment #39) > There was already one prepared: https://git.eclipse.org/r/#/c/118644/ > Merged that now. N&N should mention that default is off.
New Gerrit change created: https://git.eclipse.org/r/118784
Gerrit change https://git.eclipse.org/r/118784 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=d6b5a1dc37fa9df0bcf0b6e875ea39fcb9e0e735
Updated N&N
Thanks Karsten, this has been long awaited :) Regarding N&N entry: apparently you didn't see the part of the instructions that links to the XHTML validation service - I removed a spurious <p> to make the document well-formed again ... (part of http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=798aa3c1974a1e177b3fc5048808abd7f485628a ).
Any reason why this feature is limited to the package explorer? I personally use the Project explorer intensively and I think the setting should also apply there too (maybe other places?)
Yes, there were technical limitations. I think I have commented on this in the change.
*** Bug 548563 has been marked as a duplicate of this bug. ***
*** Bug 551076 has been marked as a duplicate of this bug. ***
