Bug 207503 - IProvisionerWizard API limits P2 target provisioner
Summary: IProvisionerWizard API limits P2 target provisioner
Status: RESOLVED INVALID
Alias: None
Product: PDE
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Curtis Windatt CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-25 15:51 EDT by Curtis Windatt CLA
Modified: 2007-12-06 17:51 EST (History)
5 users (show)

See Also:


Attachments
Proposed Changes (7.56 KB, patch)
2007-10-25 15:51 EDT, Curtis Windatt CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Curtis Windatt CLA 2007-10-25 15:51:00 EDT
Created attachment 81195 [details]
Proposed Changes

IProvisionerWizard has a method getLocations() that returns an array of File objects.

Currently the API assumes that all of the returned Files represent directories to search.  This is limiting for the p2 target provisioner as we may not want every plug-in in a directory to be added to the target.

We are proposing that the javadoc wording on the API method and the implementation of TargetPluginsTab.handleAdd() be changed to allow the returned array to contain any combination of directories (which will be searched as before) and files (which will be checked for existence and then added to the target).
Comment 1 Curtis Windatt CLA 2007-10-25 15:54:20 EDT
Unclear whether these changes will be enough for p2 (might need to store more information about the target).  The API changes should wait until things are cleared up.  However, comments on the proposed change are welcome.
Comment 2 Brian Bauman CLA 2007-10-26 16:19:47 EDT
We've got some work to do on this one.  I see two problems with the patch:

1. If we allow the File objects to be plug-ins, we currently are not able to deal with plug-ins in directory form.  They will not show up.

2. We can add jarred bundles, but upon restart they disappear.

I think we might have to consider holding off until after M3 because these aren't super simple problems to fix.
Comment 3 Darin Wright CLA 2007-10-29 22:45:08 EDT
OK, so what if we keep the existing IProvisioningWizard interface, but add a second interface (IProvisioningWizard2) that allows the enabled set of plug-ins to be specified? This would allow us to return multiple locations containing plug-ins and set the enabled ones in one action. This will support the case where locations containing plug-ins are > 1, and only some plug-ins from each location are required.
Comment 4 Pascal Rapicault CLA 2007-11-07 20:27:58 EST
> 1. If we allow the File objects to be plug-ins, we currently are not able to
deal with plug-ins in directory form.  They will not show up.

What about the following logic:
- if it is a file (isFile()), then no doubt it is a jar'ed plug-in
- it it is a folder and there is a META-INF/Manifest.MF or a plugin.xml, then it is a folder style plugin, otherwise it is a folder containing plugins (like you do today).
Comment 5 Curtis Windatt CLA 2007-12-06 17:48:34 EST
Looks like we'll be dealing with things in a different manner.  No need for changes to the IProvisionerWizard.  Marking as INVALID.