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

Bug 430655

Summary:	[target] .target definitions fail to recover after Network connection changes
Product:	[Eclipse Project] Equinox	Reporter:	Alvaro Sanchez-Leon <alvaro.sanchez-leon>
Component:	p2	Assignee:	P2 Inbox <equinox.p2-inbox>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	major
Priority:	P3	CC:	curtis.windatt.public, eclipse.sprigogin, malaperle, mleone
Version:	3.10.0 Luna
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Alvaro Sanchez-Leon

2014-03-18 21:48:18 EDT

When switching network environments e.g. Proxy <--> Direct, 
and the user attempts to manipulate the target definitions (e.g. edit it from the "Target Platform" preference page)  before adjusting to the available network connection. 

The target definition update will take long time and report "Unable to locate installable unit...." for each repository location.

After adjusting the proxy settings to the available network the errors will persist and visible from the editor of preference page.

 * The errors will persist after Restarting Eclipse
 * Attempting a reload from the target definitions preference will also fail "Unable to locate installable unit...."

The Work around which seems to recover this situation faster is to 
  1) Backup a copy of the target definitions file
  2) From the "Target Platform" preference page, "Remove" the target definition (NOTE: This will delete the file in the file system)
  3) Restore the target definitions (e.g. git reset --hard)
  4) Go back to the "Target Platform" preference page select it and press OK (this will now reload the dependencies)
  5) If unexplained compilation errors occur, restart the system

The above was reproduced using the CDT project
url = git://git.eclipse.org/gitroot/cdt/org.eclipse.cdt.git
target definitions project: /org.eclipse.cdt.target
target definitions file: cdt-staging.target

Comment 1 Curtis Windatt

2014-03-19 10:31:13 EDT

I'm not sure what PDE can do about this issue.  p2 is caching information about the remote repositories.  Even if there is a way for PDE to clear the cache (on a reload for example), I'm not certain that we should do so because of the performance hit to recheck all the remote repositories.

Your comment that updating takes a long time before failing makes me wonder if something else is going on.

Moving to p2 to see if it is even possible to clear the cache.

Comment 2 Marc-André Laperle

2014-04-29 17:12:45 EDT

I've seen this quite a few times now. I've been able to workaround the issue by restarting Eclipse (p2 cache clear?) then incrementing the sequence number (PDE cache clear?). But this is not ideal. I wish there was a refresh button to make it easier to force it to reload.

(In reply to Curtis Windatt from comment #1)
> Even if there is a way for PDE to clear the
> cache (on a reload for example),

On a reload of the target definition? When reopening it in the editor for example?

> I'm not certain that we should do so
> because of the performance hit to recheck all the remote repositories.

Maybe it could be done only if it could not contact a remote repository.

> Your comment that updating takes a long time before failing makes me wonder
> if something else is going on.

I think it takes long because it needs to timeout first for every repository before it displays the errors.

> Moving to p2 to see if it is even possible to clear the cache.

I wonder if the Reload button in the Available Software Sites could provide a hint on how to do that. I'll investigate a bit.

Comment 3 Mark Leone

2014-08-12 16:19:28 EDT

Is there still no fix for this? Loading targets is at the core of RCP development. Luna is unusable for me for any RCP development because of this bug.

I've tried workarounds mentioned here, and they don't work. That is, I tried incrementing the sequence counter and re-starting the IDE. I also tried removing the target from the preference page and then restoring the file. I downloaded the latest version of Luna today,and created a fresh workspace. No matter what I do, eclipse does not recognize any installable unit from any location.

Comment 4 Curtis Windatt

2014-08-12 16:28:30 EDT

I believe this is really a dupe of 439034.  In 4.4 M1 PDE now deletes the cached profile information if an error is returned from the p2 operation.

*** This bug has been marked as a duplicate of bug 439034 ***

Comment 5 Mark Leone

2014-08-12 18:10:19 EDT

Thanks, but I've downloaded several different versions and they all have this problem. Perhaps I'm not identifying 4.4 M1 properly.

I went here:

http://download.eclipse.org/eclipse/downloads/

and I downloaded the first build under Mainetntance Build, dated AUg 6, 2014: this link: http://download.eclipse.org/eclipse/downloads/drops4/M20140806-0900/

I also trued the 4.5 M1 since I read elsewhere that the 4.4 fix is actually a backport from 4.5. So I tried the 4.5 M1 build under Stable Builds

None of these are explicitly labeled 4.4 M1, but I would think that the latest build under 4.4 Maintenance builds would be appropriate.

All the builds above, and several others, exhibit the problem described for his bug.

Comment 6 Curtis Windatt

2014-08-13 09:39:51 EDT

(In reply to Mark Leone from comment #5)
> Thanks, but I've downloaded several different versions and they all have
> this problem. Perhaps I'm not identifying 4.4 M1 properly.
> 
> I went here:
> 
> http://download.eclipse.org/eclipse/downloads/
> 
> and I downloaded the first build under Mainetntance Build, dated AUg 6,
> 2014: this link:
> http://download.eclipse.org/eclipse/downloads/drops4/M20140806-0900/
> 
> I also trued the 4.5 M1 since I read elsewhere that the 4.4 fix is actually
> a backport from 4.5. So I tried the 4.5 M1 build under Stable Builds
> 
> None of these are explicitly labeled 4.4 M1, but I would think that the
> latest build under 4.4 Maintenance builds would be appropriate.
> 
> All the builds above, and several others, exhibit the problem described for
> his bug.

Sorry, I meant 4.5 M1.

When you tried 4.5 M1 did you try with a new workspace?  The fix only deletes the profile when it resolves with errors, if you are using an existing workspace and target definition, the cached profile will still exist.  You can try forcing a refresh by adding another target location, then removing it.