Bugzilla – Full Text Bug Listing
| Summary: | Profile as repository from other install results in dropins scanning everything | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Andrew Niefer <aniefer> | ||||
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | dj.houghton, irbull | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
|
Description
Andrew Niefer
The same applies to ExtensionLocationMetadataRepository Created attachment 168180 [details]
patch
I would suggest that when the profile is loaded as a repository, we do not want to add the extension locations to the set of artifact repositories.
In general, it is likely we are going to be loading the profile from another install, so the ExtensionLocationArtifactRepository#getLocalRepositoryLocation will be wrong. The metadata for any dropped-in bundles should already be synchronized and in the profile
BTW, PDE is adding profiles to its list of repositories during build/export which is how this was found. Removing target milestone. The real problem here isn't so much that we are loading the extension location, but rather than it has no filter and generates metadata for everything instead of just the dropped in things. I see a few problems here: 1) ExtensionLocationArtifactRepository#getLocalRepositoryLocation is wrong because we are a different install 2) When we create a new location which was the result from (1), we create a local repository without a Site policy, this means we just get a basic DirectoryChangeListener and not a SiteListener with a BundlePoolFilteredListener 3) If we did use a site listener here, the BundlePoolFilteredListener constructor is using the bundle pool for the running install, which again is the wrong answer here. The profile we are loading knows the location of its bundle pool and that it would want a site policy. The problem is getting this information over to the extension location code. This bug originally seemed like a big problem for PDE export/build, which is why it was originally targeted at 3.6. However, PDE can avoid this problem in most cases by fixing bug 312687 This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |