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

Bug 329604

Summary: [target] Presentation of duplicate bundles
Product: [Eclipse Project] PDE Reporter: Jeff McAffer <jeffmcaffer>
Component: UIAssignee: PDE-UI-Inbox <pde-ui-inbox>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: curtis.windatt.public, gunnar
Version: 3.7   
Target Milestone: ---   
Hardware: PC   
OS: Mac OS X - Carbon (unsup.)   
Whiteboard: stalebug

Description Jeff McAffer CLA 2010-11-05 22:53:06 EDT 
There are a couple ways we could improve the presentation of duplicate bundles in the target workflows.

When looking at target content with no grouping, the purpose is to show the user what bundles are available and included.  The notion of included is target-scoped.  As such, there is no need to present or maintain duplicates.

In the code the TargetContentGroup asks the target def for all bundles and uses that as the base for presentation. This list should have duplicates eliminated.  

Conversely, when grouping by location, you want to see what is in the target because of a particular location.  This is clear for dir, install and feature containers.  For IU containers it is a little fuzzier since a repo with one iu can cause 500 IUs to be added to the target.  Those IUs may come from any repo (explicitly listed or not).  The subtle difference is between containment (for dirs/installs/...) and reference/implication for IU containers.  I'm not sure how to convey this but computing strict containment in the case of IU containers would be expensive.

I spent some time with our friend TargetContentGroup trying to get something working.  The problem is that it sometimes uses the cached fAllBundles and sometimes does fTarget.getBundles or getAllBundles. Further, the checkedState infrastructure also knows the counts. 

I'd be happy to help sort this out but someone with more familiarity will be needed to drive the change.
Comment 1 Curtis Windatt CLA 2010-12-01 16:05:55 EST 
Jeff, is this something that will be integrated into bug 331068?
Comment 2 Jeff McAffer CLA 2010-12-01 16:15:22 EST 
No unfortunately not.  I tried somethings to get the duplicate removal effects I wanted and they all worked fine but the element counts were all off and there was some weirdness around unchecking things.  I just don't have enough familiarity with the UI and that fancy check box state stuff.  I think we should keep this bug open/separate.

I'm still happy to work with someone who can drive the UI part.
Comment 3 Eclipse Genie CLA 2019-03-27 02:21:19 EDT 
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 4 Lars Vogel CLA 2019-10-08 10:47:52 EDT 
This bug was marked as stalebug a while ago. Marking as wontfix.

If this report is still relevant for the current release, please
reopen and remove the stalebug whiteboard tag.