Community
Participate
Working Groups
in creating a new target platform in a new workspace the user often will include at least some bundles that are already present in on their local machine. For example, org.eclipse.osgi and various runtime bits if not more like SWT, UI, ... Assuming a corelation between IDE and target versions (common though not exclusive) all of these things are in the current running Eclipse. Further, it is often the case that various other workspaces have target material in them. Many of these are known to the current running eclipse (e.g., switch workspace info). The PDE target bundle pools present there could be used to supply content for the new target platform.
Created attachment 181899 [details] proposed solution This patch adds a number of discovered artifact repos for consideration when resolving a target with software sites. First it adds in a artifact repos related to the currently running profile, typically the IDE profile. This will get the bundlepool (typically eclipse/plugins), the dropins folders, etc. Second we try to find any known workspaces and use the pde target bundle pool from there. Currently the only source of workspace locations is the UI's "recent workspaces" preference. If this direction feels good I suggest we consider the following: - a mechanism to disable this so only the repo listed in the site are used. This will be relevant when somehow random bundles are in place with bogus version numbers etc. This should be rare but will be completely debilitating if it happens. Could perhaps be handled with a system property (gag) or a preference. - a UI affordance for defining or managing an explicit set of artifact repos to use.
(In reply to comment #1) > - a UI affordance for defining or managing an explicit set of artifact repos to > use. Before, it was requested that the bundle pool which we download to could be set to a specific directory. Rather than controlling the bundle pool location, do you think it would be enough for users to be able to add other artifact repo locations as you have suggested here?
I think those are somewhat separate but related things. Sharing the bundle pool amongst workspaces has its own challenges wrt garbage collection and concurrent access. While it would be highly desirable, there is IMHO considerable other work to be done beforehand. Allowing people to identify sources of artifacts is a step but the artifacts are still going to be copied. Note that if we do add this affordance, it should be suitably abstract. For example, users should be able to point at a workspace and get the PDE target bundle pool (i.e., without having to know .metadata/.plugins/...). So like, add a repo, add a workspace, add an install
A slightly updated version of this patch has been consolidated with several other overlapping patches and attached to bug 328929. discussion of issues related to this enhancement should continue here. The consolidated patch is just to ease application.
Fixed in HEAD. Thanks for all the great work Jeff!
Verified in I20101208-0800
