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

Bug 114779

Summary: PDE UI doesnt allow plug-in exporting unless target platform environment matches the plug-in platform filter
Product: [Eclipse Project] PDE Reporter: Daniel M. Schumacher <danschum>
Component: UIAssignee: Brian Bauman <baumanbr>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: aniefer, baumanbr, bpasero, dwijenay, emorning, khorowit, mpcarl, tjwatson, wassim.melhem
Version: 3.2Flags: wassim.melhem: review+
Target Milestone: 3.3 RC1   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Patch for Problem #2 (will not fix entire bug)
none
patch for the first problem
none
refactored patch for first problem baumanbr: review?

Description Daniel M. Schumacher CLA 2005-11-02 11:33:12 EST 
A couple of issues here...

I have several plug-ins that make use of the Eclipse-PlatformFilter header, 
filtering on os/ws/arch.  Trying to export all of these plug-ins at once from 
the workspace results in only one os/ws/arch combination to be produced, with 
no indication as to why the others aren't being exported.  Seems I can only 
export a plug-in if it matches the current target platform environment, and 
that only allows me to set one configuration (not multiple configurations like 
I'm able to do in PDE build).

Also, I have noticed that when I modify a value in the target platform 
environmnet (say, the Architecture from win32 to arm -- typed in, since it's 
editable and arm is not available in the dropdown) the setting does not take 
effect until the target platform is reloaded.  And when I close the 
preferences and then reopen and return to the target platform environment 
settings, the Architecture dropdown now shows "arm,arm".
Comment 1 Wassim Melhem CLA 2005-11-15 11:22:02 EST 
Brian, 

Issue #2 becomes easier to solve after fixing bug 114642.  When the target 
environment changes, we should do a full non-incremental resolve on the state 
and recompute the classpaths on all workspace plug-ins.

After you're done, reassign the defect to me and I will see what we can do 
about issue #1
Comment 2 Brian Bauman CLA 2005-11-21 14:58:50 EST 
Created attachment 30330 [details]
Patch for Problem #2 (will not fix entire bug)
Comment 3 Wassim Melhem CLA 2006-04-19 18:16:36 EDT 
*** Bug 129180 has been marked as a duplicate of this bug. ***
Comment 4 Brian Bauman CLA 2007-05-01 14:24:24 EDT 
*** Bug 184838 has been marked as a duplicate of this bug. ***
Comment 5 Brian Bauman CLA 2007-05-04 10:07:11 EDT 
*** Bug 185454 has been marked as a duplicate of this bug. ***
Comment 6 Wassim Melhem CLA 2007-05-15 01:39:14 EDT 
*** Bug 109132 has been marked as a duplicate of this bug. ***
Comment 7 Wassim Melhem CLA 2007-05-15 01:40:30 EDT 
*** Bug 173318 has been marked as a duplicate of this bug. ***
Comment 8 Brian Bauman CLA 2007-05-15 16:19:27 EDT 
Created attachment 67310 [details]
patch for the first problem

This patch will fix the problem of not being able to export a plug-in if its platform filter does not match the current target environment.

The fix is a brilliant idea from Wassim.  PluginExportOperation extends the createFeature.  It iterates through the objects to be exported to find BundleDescriptions.  If a BundleDescription has a conflicting platform filter, we copy our current resolver state, remove the BundleDescription, create a copy (minus the platform filter) and add it back to the resolver state.  This allows the bundle to actually be resolved and found by PDE build on export.

The last piece of the fix is PluginExportOperation extending getState().  This function is called when setting the State in PDE Build.  The implementation in PluginExportOperation will return the copied state if we had to make a copy.
Comment 9 Brian Bauman CLA 2007-05-15 16:20:08 EDT 
Wassim, can you review this patch when you get a chance.
Comment 10 Brian Bauman CLA 2007-05-15 17:30:12 EDT 
Created attachment 67325 [details]
refactored patch for first problem

In an effort to minimize the changes to the parent class (since we are later in the development cycle), I duplicated a lot of code in the first patch.  This patch cuts down on the code duplication while implementing the same (awesome) algorithm.
Comment 11 Wassim Melhem CLA 2007-05-15 21:34:53 EDT 
Patch works well.  Bauman is awesome.

Problem #1 was addressed in bug 184041