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

Bug 262964

Summary: Unable to remove/disable repository
Product: [Eclipse Project] Equinox Reporter: Matthew Piggott <matthew>
Component: p2Assignee: John Arthorne <john.arthorne>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P2 CC: eclipse, irbull, Markus.Milleder, pascal, pforeman
Version: 3.5   
Target Milestone: 3.5 M6   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Modifies AbstractRepositoryManager to use ProfilePreferences rather tahn Configuration
none
Updated ArtifactRepositoryManagerTest
none
Modified Repository Actions
none
Updated Repository Action tests
none
Modified Repository Actions
none
SimpleProfileRegistry patch none

Description Matthew Piggott CLA 2009-01-29 15:34:15 EST
1) Start with a new install of Eclipse SDK 3.5-I20090129-0100
2) Disable all repositories
3) Restart Eclipse
4) Open the Installation Information window and all repositories will be re-enabled

1) Start with a new install of Eclipse SDK 3.5-I20090129-0100
2) Remove all repositories
3) Open the Installation Information window and all repositories are re-added & enabled

This also occurs with Eclipse SDK 3.5-I20090127-0100

Pascal believes that this affects repositories which have been added by Configuration Units and are re-added as they are present in the profile.
Comment 1 Pascal Rapicault CLA 2009-01-29 15:39:39 EST
I think this is fairly important to address since it does not give ppl the appropriate control of repo when plug-ins are adding repos.
Comment 2 John Arthorne CLA 2009-01-29 22:24:21 EST
Correct, repositories present in the profile are added to the repository managers on startup. They are only removed when the corresponding IU is uninstalled. This made sense to me at the time, but I think if we allow a user to disable/remove them, that should be honoured on the next startup.
Comment 3 John Arthorne CLA 2009-02-04 09:42:59 EST
*** Bug 263614 has been marked as a duplicate of this bug. ***
Comment 4 Matthew Piggott CLA 2009-02-18 13:04:06 EST
Created attachment 126052 [details]
Modifies AbstractRepositoryManager to use ProfilePreferences rather tahn Configuration
Comment 5 Matthew Piggott CLA 2009-02-18 13:09:57 EST
Created attachment 126054 [details]
Updated ArtifactRepositoryManagerTest

One of the tests for ArtifactRepositoryManager worked with the assumption that repository information would be stored in ConfigurationScope preferences.  This simply updates the test to self profile preferences.
Comment 6 Matthew Piggott CLA 2009-02-19 13:51:26 EST
Created attachment 126195 [details]
Modified Repository Actions
Comment 7 Matthew Piggott CLA 2009-02-19 13:51:48 EST
Created attachment 126196 [details]
Updated Repository Action tests
Comment 8 Matthew Piggott CLA 2009-02-19 13:58:18 EST
Created attachment 126198 [details]
 Modified Repository Actions 

Missed the MANIFEST.MF in the previous patch
Comment 9 John Arthorne CLA 2009-02-19 17:22:41 EST
All patches on this bug are replaced with the patch on bug 265315. I combined the patches because it was becoming difficult to keep them separate.
Comment 10 Susan McCourt CLA 2009-02-19 18:59:27 EST
*** Bug 264270 has been marked as a duplicate of this bug. ***
Comment 11 Matthew Piggott CLA 2009-02-24 10:42:38 EST
Created attachment 126565 [details]
SimpleProfileRegistry patch

This removes the publishRepositoryReferences and associated methods which are pushing repositories stored in the profile to preferences.
Comment 12 John Arthorne CLA 2009-02-24 13:19:38 EST
Matthew, can you enter a separate bug for your patch in comment #11? We need to leave that code in place at least for M6 because there is a delay before we start using the new engine in the build. It won't hurt to leave that code in place for M6 because once the repos are not being added to the profile, this will be a no-op anyway.
Comment 13 Matthew Piggott CLA 2009-02-24 13:38:21 EST
Comment on attachment 126565 [details]
SimpleProfileRegistry patch

Sure, I've opened bug 265994 for this change.
Comment 14 John Arthorne CLA 2009-02-25 09:49:12 EST
*** Bug 266110 has been marked as a duplicate of this bug. ***
Comment 15 John Arthorne CLA 2009-02-27 11:58:39 EST
I verified this is fixed by looking at the output of a test build from yesterday:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=266292

This bug will be fixed for end-users in the next integration build.