Bug 363832 - [patch] [target] Resolution fails with "...is a folder but the repository is an archive or remote location" if recent workspaces have relative path
Summary: [patch] [target] Resolution fails with "...is a folder but the repository is ...
Status: RESOLVED FIXED
Alias: None
Product: PDE
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.7   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 3.8 M4   Edit
Assignee: Curtis Windatt CLA
QA Contact:
URL:
Whiteboard:
Keywords: contributed
Depends on:
Blocks:
 
Reported: 2011-11-15 09:32 EST by Tobias Oberlies CLA
Modified: 2011-11-22 11:41 EST (History)
1 user (show)

See Also:

Attachments
Fix: Add recent workspace bundle pools as absolute URIs (2.45 KB, patch)
2011-11-15 10:27 EST, Tobias Oberlies CLA 		curtis.windatt.public: iplog+
Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Oberlies CLA 2011-11-15 09:32:53 EST 
Steps to reproduce:
1. start Eclipse with a relative workspace location, e.g. "../ws"
2. import a project with a target file
3. open the target file
4. click on "Set as Target Platform" -> so far this works as expected

5. switch to a different workspace, e.g. "../ws2"
6. import the same project as in 2
7. open the same target file as in 3
8. click on "Set as Target Platform"

-> This results in an error of the following form

Problems occurred getting the plug-ins in this container
An error occurred while collecting items to be installed
session context was:(profile=TARGET_DEFINITION:resource:/<your-project-here>/<your-target-file-name-here>.target, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=).
Artifact org.eclipse.update.feature,<some-id>,<some-version> is a folder but the repository is an archive or remote location.
Artifact org.eclipse.update.feature,<next-id>,<next-version> is a folder but the repository is an archive or remote location.
...
Comment 1 Tobias Oberlies CLA 2011-11-15 10:11:51 EST 
For tracing this problem, place breakpoints in the following locations before step 6:
a) entry of org.eclipse.pde.internal.core.target.P2TargetUtils.findWorkspaceRepos(Set)
b) second line (after isFolderBased check) of org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.downloadArtifact(IArtifactDescriptor, OutputStream, IProgressMonitor)

When hitting breakpoint a, make sure that @recent@ contains the relative path to the workspace location of step 1 so that @new File(bundlePool).exists()@ passes. This works out of the box in normal installations - if Eclipse is started as PDE run configuration, the @recent@ variable needs to be changed with the debugger.

When hitting breakpoint b, step into getArtifactFile, getLocation and see how the mapper does something different with the invalid, opaque file URI as the rest of the broken p2 URI handling.

You may claim that this is a p2 bug, but IMHO the whole URI handling in p2 is broken beyond repair. (feel free to open a bug report on p2, but I won't.)
Therefore, I would say that this is a PDE bug: org.eclipse.pde.internal.core.target.P2TargetUtils.findWorkspaceRepos(Set) should only produce valid file URIs (as defined by java.io.File) in the first place and just not run into this p2 trap.
Comment 2 Tobias Oberlies CLA 2011-11-15 10:27:30 EST 
Created attachment 207034 [details]
Fix: Add recent workspace bundle pools as absolute URIs
Comment 3 Curtis Windatt CLA 2011-11-22 11:36:05 EST 
Applied the patch to HEAD.  It is an edge case, but the provided code is a better way to create the URIs.  Thanks.