Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 26642

Summary: Improvement of "Compress package name segments" [package explorer]
Product: [Eclipse Project] JDT Reporter: Boris Pruessmann <boris>
Component: UIAssignee: JDT-UI-Inbox <jdt-ui-inbox>
Status: RESOLVED WONTFIX QA Contact:
Severity: enhancement    
Priority: P3 CC: bnbatkins, boris, jan.materne
Version: 2.1   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on: 22208    
Bug Blocks:    
Attachments:
Description Flags
Patch based on today's CVS none

Description Boris Pruessmann CLA 2002-11-19 03:01:21 EST 
I think it would be a good idea if one could provide segment patterns that 
would always be stripped when displaying a package name, e.g. I would 
define "org.eclipse" and the packages would appear as core, internal.core etc. 
IMHO, most people will find such prefixes in their package names, so giving an 
option to strip those would be great.

The current feature does not seem to provide such a feature in a convenient 
way. Specifying e.g. "0." would lead to package names like core and core (see 
example above) which makes the feature unusable in the scenario above.
Comment 1 Boris Pruessmann CLA 2002-12-22 07:31:48 EST 
Created attachment 2865 [details]
Patch based on today's CVS
Comment 2 Boris Pruessmann CLA 2002-12-22 07:39:00 EST 
Finding this issue _very_ annoyning, I decided to do it myself. After applying the attached 
patch you can configure Eclipse to strip leading parts of package names. Parts to remove 
can be configured via the Java/Appearance preferences page.

I would greatly appreciate if you could include this patch in 2.1 because it's imho superior 
to the compression mechanism as in most cases developers deal with packages within 
one hierarchy e.g. org.eclipse, net.sourceforge, com.ibm etc.
Comment 3 Dani Megert CLA 2003-01-06 05:39:32 EST 
There is another request for more package compression options (see bug 22208).
We won't support list and patterns. Would the additional patterns fit your needs?
Comment 4 Robert Varga CLA 2003-01-06 05:59:27 EST 
The patch I submitted in bug #22208 is quite flexible, and will allow to handle 
most scenarios. 

It is able to strip away or compress multiple sections of varying numbers of 
package name segments, compression in each section configurable separately, and 
sections can be given strictly or allowingly (only if there are segments after 
the section), and the last section can also be specified as 
the last-but-'n' segments.

For a workbench where a package naming convention is enforced, this is enough.
Also if the package name depth after the common part is uniform, this is also 
enough.

Possible extensions could be to provide the package name compression pattern 
separately for each project, or maybe even separately for each source folder.



On the other hand, lists of package name roots to be replaced with something is 
however another useful and maybe more easily configurable feature, although it 
may have a problem with hierarchical package layout.
Comment 5 Boris Pruessmann CLA 2003-02-04 11:12:32 EST 
Just give it a try then....
Comment 6 Boris Pruessmann CLA 2003-10-12 11:00:41 EDT 
Just out of curiosity: there are at least two contributions for this enhancement request for at least 
9 month. Can we expect that one of them will be included in the near future?
Comment 7 Dani Megert CLA 2003-10-13 04:36:34 EDT 
It's currently not on the plan. We have other items which need to be done first
and/or have (more) votes.
Comment 8 Michael Dinsmore CLA 2005-12-22 10:06:29 EST 
I see Robert Varga had made an attempt at fixing the problem for bug #22208 [which really is a duplicate of this bug].  It looks like Boris Pruessmann also took some time to solve the issue as well.  It appears that some honest attempts are being made to resolve this issue.  The current implementation just isn't suitable for large-scale enterprise projects where there's a large variery of packages.  JDeveloper, IntelliJ both have a better method where it utilizes screen space much more effiently while removing redundant information from the  view.  

Both this bug and bug #22208 are set to 'RESOLVED' status, yet the problem continues to fester.  Do issues that are labelled 'RESOLVED' get looked at, or are they just bypassed as only the 'OPEN' ones get attention (reviewed for votes)?  The online documentation seems to say that decision is the individual team's choice:  "Once a bug is resolved there are still a few states it can transition too.  How you choose to use these states will be up to individual teams." (https://bugs.eclipse.org/bugzilla.html)


Should a new bug be opened for the Version 3.x code?  I was reading https://bugs.eclipse.org/bugs/bugwritinghelp.html to see if that's the accepted practice and it didn't really mention anything about it.  This bug is assigned to 2.1 Version.

Thanks.
Comment 9 Dani Megert CLA 2005-12-22 10:38:52 EST 
We also track bugs that are set to LATER. I've updated bug 22208.
Comment 10 Dani Megert CLA 2009-04-21 03:07:26 EDT 
*** Bug 272929 has been marked as a duplicate of this bug. ***
Comment 11 Dani Megert CLA 2009-04-21 03:07:54 EDT 
*** Bug 118077 has been marked as a duplicate of this bug. ***
Comment 12 Eclipse Webmaster CLA 2009-08-30 02:40:04 EDT 
As of now 'LATER' and 'REMIND' resolutions are no longer supported.
Please reopen this bug if it is still valid for you.