Community
Participate
Working Groups
In order to make usage of Eclipse more consistent, it would be good to make the "Project Explorer" a good substitute for "Package Explorer" and have JDT Perspective use directly the Project Explorer. This issues tracks features that are missing in the Project Explorer to make Package Explorer useless.
There are still a lot of features missing in the 'Project Explorer'. Just look through the open bugs with "project explorer" or "common navigator" in the summary.
Some of these features are not available in the JDT Package Explorer neither. We only need to care about the ones that are in JDT Package Explorer, but not in Resource "Project Explorer" (that could be called Workspace Explorer). If there are some important features you know should be added to this list, please add them as dependencies. The issue with having 2 explorers is that it cost twice more maintenance, and reduce consistency and ergonomics of the IDE. It would make things easier for contributors and users of there were a single universal explorer, and it seems to me that it's something that seems technically achievable without major effort, just one step after the other to port some or rewrite some existing featuress.
(In reply to Mickael Istria from comment #2) > Some of these features are not available in the JDT Package Explorer neither. Right, you need to pick those that mention the Package Explorer. > If there are some important features you know should be added to this list, >please add them as dependencies. Most of them are important to one or the other person. > The issue with having 2 explorers is that it cost twice more maintenance, At this point there's almost no cost/maintenance invested. On the other hand, adding new features to the Project Explorer and fixing the initial bugs, is a lot of work.
Although I understand this is an effort that you don't plan because, I'm just wondering whether the general idea of merging both explorers makes sense to you, and whether you agree with the benefit for end-users ?
(In reply to Mickael Istria from comment #4) > Although I understand this is an effort that you don't plan because, I'm > just wondering whether the general idea of merging both explorers makes > sense to you, and whether you agree with the benefit for end-users ? I still see major functionality not present. If someone steps forward and fills those gaps and the Project Explorer is then at the same level as the Package Explorer, then I see no problem replacing it in the corresponding perspective(s). Note though, that I prefer spending my time reviewing new features that aren't available at all, rather than reviewing changes that just port existing features to another view. BTW, some handy features that just come to my mind without searching bugzilla: - last recently used filters in view menu - several missing features around working sets - some missing filters (e.g. text filter)
+1 for this request. We need to get rid of the language perspectives in favour of a single Edit perspective. Perspectives are a huge usability hurdle for new users. The fewer we have the better.
As a data point, I never use the Project Explorer, and whenever I unknowingly started using it (because some product enabled it), I soon realized it due to some missing feature or incorrect behavior, and instantly closed it and opened the package explorer.
Both are missing important features available in the other. Project explorer is missing features related to working sets (bug 266030 and bug 427887). Package explorer is missing an option to not filter the contents of output directories. That makes trying to fix the problem like this error message suggests quite difficult: The project was not built due to "Could not delete '/HotLoader/target/classes/com'.". Fix the problem, then try refreshing this project and building it since it may be inconsistent HotLoader Unknown Java Problem
(In reply to Rafael Chaves from comment #7) > As a data point, I never use the Project Explorer, and whenever I > unknowingly started using it (because some product enabled it), I soon > realized it due to some missing feature or incorrect behavior, and instantly > closed it and opened the package explorer. It would be helpful if you could link existing or new bugs as dependencies to actually get the list of missing features that makes the project explorer not enough.
@michael: I never reported anything because I never saw myself as an intended user of the tool, nor ever saw it as a replacement for the Package Explorer. Instead, my occasional use of the Project Explorer has always been by mere confusion (I think SpringSource has it enabled in SSTS/GGTS). I will report any unexpected behavior I notice next time I use it by accident.
This bug seems to go in the same direction as bug 208693 ([Workbench] [Navigator] [Project Explorer] Why to have two views?), which was closed as WONTFIX. The comments on the bug 208693 are applicable to this bug too. Below is a small selection of bugs from my list where I can't set the dependency to the current request, so please add them as blockers: Bug 223392 [CommonNavigator] New ToolTip API doesn't work with Common Navigator Bug 167414 [CommonNavigator] Project Explorer is missing "MRU filters" Bug 150675 [CommonNavigator] Common Navigator Framework Filter/Content Extension Dialog should be extendable Of course CommonNavigator framework has much more bugs/requests, but not all of them are applicable to this issue, see the query below: https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=Eclipse&list_id=8306902&longdesc=CommonNavigator&longdesc_type=allwordssubstr&order=Importance&query_format=advanced Also I can remember that there were subtle differences between package/project explorers in handling of file delete/move operations, caused team plugins bugs/workarounds. CommonNavigator is a complicated beast because it is trying to be both flexible and extensible. Changing a lot there would most likely break existing clients - not only because of API (will probably need to be changed) but also the behavior changes. I see the need on one universal navigator view, but I do not see resources for porting existing Package Explorer functionality to CommonNavigator. IMHO this bug has no chance to be implemented without assigning a full time developer working only on the CommonNavigator framework for the next release.
(In reply to Andrey Loskutov from comment #11) > This bug seems to go in the same direction as bug 208693 ([Workbench] > [Navigator] [Project Explorer] Why to have two views?), which was closed as > WONTFIX. Thanks for the link, that's indeed very similar. WONTFIX shouldn't be allowed. Who knows what the future is made of? Maybe if this same bug remained open, having a helpwanted flag or anything else more welcoming than a WONTFIX, this bug would already be resolved... > The comments on the bug 208693 are applicable to this bug too. > Below is a small selection of bugs from my list where I can't set the > dependency to the current request, so please add them as blockers: I added them. > CommonNavigator is a complicated beast because it is trying to be both > flexible and extensible. Changing a lot there would most likely break > existing clients - not only because of API (will probably need to be > changed) but also the behavior changes. From a usage POV, there are a lot of similarities between package and project explorers. I guess the behaviour change won't be that big, and that it shouldn't reveal too many issues. As for API, let's try to keep backward compatibility, as usual. > porting existing Package Explorer functionality to CommonNavigator. It seems to me that the gap between package explorer and project explorer is not that big. From a user POV, only working sets seem to differ. Most other stuff work the same. > IMHO > this bug has no chance to be implemented without assigning a full time > developer working only on the CommonNavigator framework for the next release. Resource assignement is a bit off-topic IMO. The entry is here, the idea seems worth it. Anyone can come and put some time in fixing a piece of it. No need to think about a full time developer or whatever. Someone having one hour to spend on this is welcome anyway.
Now that the project explorer provides nested project view, some users reported that they were willing to try this but didn't manage to find it. The reason is that they were using Package Explorer. I now believe that the user value of the Project Explorer in its current state is better than the one in Package Explorer (despite the remaining issues linked to this one). So most users who start a new workspace would be more satisfied by seeing Project Explorer and Package Explorer by default. Those who would miss a feature from Package Explorer could still use it, those who use an existing workspace would still see the Package Explorer as they're used to. Isn't it the right time to switch to the JDT perspective to Project Explorer.
Currently Project explorer wastes too much space: Bug 471587 - Referenced libraries are not grouped in Project explorer OT: Even better - I would really like a separate view for libraries - it would follow project structure but show only libraries - that would allow me to navigate source files in a project and libs without loosing context when I step into a library.
(In reply to Mickael Istria from comment #13) > Isn't it the right time to switch to the JDT perspective to Project Explorer. No, see my previous comments.
As a quick note, the Java EE perspective, which is default with the Java EE package (by far the most downloaded one) comes with the Project Explorer as default, and so far I didn't notice users complaining about it. IMO, although the Project Explorer doesn't contain all features of Package Explorer (and vice-versa), it is the most helpful for users as it supports much better much more technologies.
Bug 264404 is not a blocker from JDT POV, since JDT does contribute marker decoration anyway.
Was looking forward to trying the new "Close project via middle-click" feature, but was was caught out by the fact that it doesn't work in the Package Explorer. It would definitely be beneficial to users to have a single view, rather than two very similar but not quite identical ones. This causes a lot of confusion and frustration, as illustrated by this popular StackOverflow post about the difference between the two, asked over 10 years ago yet still active nowadays: https://stackoverflow.com/questions/1265070/what-is-the-difference-between-the-eclipse-package-explorer-and-the-eclipse-proj
Instead of removing the package explorer I suggest in Bug 552279 to use Project Explorer by default, like all other perspectives I'm aware of are doing.
(In reply to Lars Vogel from comment #19) > Instead of removing the package explorer I suggest in Bug 552279 to use > Project Explorer by default, like all other perspectives I'm aware of are > doing. You saw that this bug is not about "removing the package explorer" but about "removing the need for 'package explorer'"?
Note that a blocking bug has just been auto closed WONTFIX: bug 547844. Does it make this current bug WONTFIX, too, by transitivity?
