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

Bug 324677

Summary: Phantom classpath dependencies should be removed
Product: [WebTools] WTP Java EE Tools Reporter: Jason Peterson <jasonpet>
Component: jst.j2eeAssignee: Jason Peterson <jasonpet>
Status: RESOLVED FIXED QA Contact: Chuck Bridgham <cbridgha>
Severity: normal    
Priority: P3 CC: ccc, david_williams, jsholl
Version: 3.2Flags: david_williams: pmc_approved+
jasonpet: pmc_approved? (raghunathan.srinivasan)
jasonpet: pmc_approved? (naci.dai)
deboer: pmc_approved+
jasonpet: pmc_approved? (neil.hauge)
jasonpet: pmc_approved? (kaloyan)
cbridgha: review+
Target Milestone: 3.2.2   
Hardware: PC   
OS: Windows XP   
Whiteboard: PMC_approved
Attachments:
Description Flags
patch none

Description Jason Peterson CLA 2010-09-07 13:31:27 EDT
Created attachment 178342 [details]
patch

The ClassPathSelection class is used by an adopter to provide a list of potential and current manifest entries for the use in the adopter's manifest editor.  The entries are meant to be shown as selected/unselected based on whether they currently exist in the manifest file.  However, this is not the case for tagged/untagged classpath dependency entries:

- untagged classpath dependency entries are shown as unselected.  Selecting these does not tag the entry or update the manifest (does nothing).

- tagged classpath entries are shown as selected, meaning the entry exists in the manifest.  However, these are really just phantom entries that do not exist until runtime when the manifest is dynamicallly updated.  Unselecting these entries does nothing as well.

The WTP manifest editor does not use ClassPathSelection so these issues do not apply to it.  It also does not show classpath dependencies, which is all the more reason to remove these phantom entries from ClassPathSelection.
Comment 1 Chuck Bridgham CLA 2010-09-08 14:34:30 EDT
approved
Comment 2 Jason Peterson CLA 2010-09-08 15:15:13 EDT
  * Explain why you believe this is a stop-ship defect. Or, if it is a
"hotbug" (requested by an adopter) please document it as such. 

Claspath Dependency entries are being returned as entries that are either already in the manifest file or as entries that could be added to the manifest file on selection.  Both of these scenarios are broken. The entries are not added on selection and showing these missing entries as existing only confuses users.

    * Is there a work-around? If so, why do you believe the work-around is
insufficient? 

No workaround exists other than the user just ignoring the phantom entries.

    * How has the fix been tested? Is there a test case attached to the
bugzilla record? Has a JUnit Test been added? 

Fix has been tested in the UI.

    * Give a brief technical overview. Who has reviewed this fix? 

The ClassPathSelection class has been updated to not show these phantom manifest entries.

Chuck has reviewed this fix.

    * What is the risk associated with this fix? 

minimal - These phantom entries were only shown for display purposes and selecting and unselecting them had no affect on the manifest file.
Comment 3 David Williams CLA 2010-09-09 10:02:11 EDT
My first thought was this was a relatively minor usability issue, but IMing with Chuck, he pointed out we've had a lot of complaints about usability of "dependency UI" and while good progress has been made on other fronts, this is a remaining issue that will be important to complete that overall usability story.
Comment 4 Jason Sholl CLA 2010-09-09 12:49:35 EDT
code checked into 32M for 3.2.2 and HEAD for 3.3