Community
Participate
Working Groups
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.
approved
* 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.
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.
code checked into 32M for 3.2.2 and HEAD for 3.3
