Bugzilla – Full Text Bug Listing
| Summary: | [target] Target provisioning should use local artifact repos | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Jeff McAffer <jeffmcaffer> | ||||
| Component: | UI | Assignee: | Curtis Windatt <curtis.windatt.public> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | curtis.windatt.public, irbull, pascal | ||||
| Version: | 3.6 | Keywords: | contributed, noteworthy | ||||
| Target Milestone: | 3.7 M4 | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Jeff McAffer
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 |