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

Bug 241430

Summary: Limit director repository list to provided URLs
Product: [Eclipse Project] Equinox Reporter: Rich Scott <rscott>
Component: p2Assignee: Andrew Niefer <aniefer>
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: aniefer, any, cfraser, chewi, cpuidle, estradas, francisu, irbull, jdmiles, jluo, mpcarl, pascal, richard.gronback, sflaniga, spektom
Version: 3.5   
Target Milestone: 3.5 M4   
Hardware: PC   
OS: Windows XP   
URL: http://www.eclipse.org/newsportal/article.php?id=4946&group=eclipse.technology.equinox#4946
Whiteboard:

Description Rich Scott CLA 2008-07-18 15:05:03 EDT 
Currently,  when using p2 director to install an RCP application from a local repository,director will attempt to locate components on the Ganymede download site. It would be very useful to have a means to limit director's access to only the repository provided.

I ran across the situation while tyring to install from a local repository with a file: URL for both -metadataRepository and -artifactRepository.  My assumption
has been that all access to locate file to install has been from the
provided local directory. However, on one occaision I got the stack trace
which indicated that the connection to http://download.eclipse.org/releases/ganymede timed out. It had never been seen before because it was all happening quietly.

If interested, the stack trace is in the new posting at http://www.eclipse.org/newsportal/article.php?id=4946&group=eclipse.technology.equinox#4946
Comment 1 Pascal Rapicault CLA 2008-07-22 08:46:45 EDT 
*** Bug 235491 has been marked as a duplicate of this bug. ***
Comment 2 Andrew Niefer CLA 2008-09-25 13:57:10 EDT 
*** Bug 248633 has been marked as a duplicate of this bug. ***
Comment 3 Andrew Niefer CLA 2008-10-01 12:11:15 EDT 
This may just be bug 241430.  Try removing the  configuration/.settings/org.eclipse.equinox.p2.*.repository.prefs files from the director install before running.
Comment 4 Chris Fraser CLA 2008-10-01 12:37:36 EDT 
This problem also happens with a new installation, so deleting the .prefs file isn't an option.
Comment 5 Andrew Niefer CLA 2008-10-01 13:07:40 EDT 
Sorry, that comment #3 was meant for a different bug.  However, note that the SDK ships with those preferences prepopulated, so a fresh install will have them as well.
Comment 6 Andrew Niefer CLA 2008-12-05 13:44:11 EST 
I'm doing this.
Comment 7 Andrew Niefer CLA 2008-12-05 17:44:03 EST 
done.
Both the query for the set of root IUs to install and the actual ProvisioningContext have both been changed to only use the passed in repositories.

The application now also cleans up behind itself and removes from the repo managers the repositories that it added that weren't there previously.
Comment 8 John Arthorne CLA 2009-04-17 13:28:01 EDT 
*** Bug 271242 has been marked as a duplicate of this bug. ***
Comment 9 Michael Spector CLA 2009-06-16 04:20:21 EDT 
I still encounter this bug in 3.5.0RC3. When opening an update wizard in the exported product I get the message: "No repository found at: /tmp/builld/..."
Comment 10 John Arthorne CLA 2010-01-07 16:23:39 EST 
(In reply to comment #9)
> I still encounter this bug in 3.5.0RC3. When opening an update wizard in the
> exported product I get the message: "No repository found at: /tmp/builld/..."

I am re-closing this bug and reopening bug 271242 instead. This bug was really about the director contacting extra repositories during install, which is fixed. Your issue is about the repositories added by the director sticking around after the director has finished. Andrew attempted to address both of these issues in this single bug, but it appears from your comment that it's not working. Let's continue with that issue in bug 271242.