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

Bug 340014

Summary:	Offer a quick fix to install missing dependencies from p2 repositories
Product:	[Eclipse Project] PDE	Reporter:	Aaron Digulla <digulla>
Component:	UI	Assignee:	PDE-UI-Inbox <pde-ui-inbox>
Status:	RESOLVED INVALID	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	curtis.windatt.public
Version:	3.7
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Aaron Digulla

2011-03-15 09:15:38 EDT

Build Identifier: 3.6.1

Imagine the following situation: A newbie downloads an Eclipse project for, say, GEF and barely manages to unpack it into his workspace. Now he has lots of compile errors because the dependencies of the new projects aren't installed as plug-ins in his IDE.

To solve this situation, I'd like two enhancements:

1. There should be a quick fix which offers to download all missing dependencies from known p2 repos.

2. When a bundle/project is packaged, a PDE build step should add a file which contains the list of p2 repositories that contain the dependencies used in the build.

With the second feature, the quick fix could offer to temporarily enable new p2 repos to resolve missing dependencies.

Reproducible: Always

Comment 1 Curtis Windatt

2011-03-15 10:33:02 EDT

For (1), see Bug 304279 and Bug 304273.

For (2), we already provide the list of repositories to PDE Build, see Bug 308943.  I don't see any benefit in writing out a new file with the information.

I think this bug should be closed as WORKSFORME, but I'll let Aaron respond first.  If you are willing to work on improving the quick fix support that would be awesome as it is currently a little flaky.

Comment 2 Aaron Digulla

2011-03-15 11:32:04 EDT

What do you mean by "list of repositories to PDE Build"? That sentence doesn't make sense for me.

Where is that list? When I have missing dependencies, can I be sure that the list will work for me? Can Eclipse find and use this list automatically?

You see, as someone new to Eclipse, this is all a huge black box and people don't even know where to start looking (for example, they won't know about p2). But during the build of something, this information is available. Eclipse knows where it got everything from. Even if it's just the name of an archived p2 repo sitting on the disk: Eclipse could at least tell the user what to Google for.

As for Bug 304279 and Bug 304273: The first bug says "TODO", the second one says "RESOLVED FIXED".

Is it implemented? Or should the second bug be a duplicate of the first one instead of "RESOLVED FIXED"?

Comment 3 Curtis Windatt

2011-03-15 12:03:02 EDT

There is support for adding packages from remote repositories. If you are missing a necessary import, there is a quick fix to 'search repositories' that will try to add the necessary package to your target platform.

Bug 304279 was never completed, and the user who was working on it has stopped working on PDE enhancements. It's goal is the same as missing package, but would add a bundle to the target platform and your manifest.

You haven't explained why you need a list of repositories in a file, where those repositories should come from, or where we would put the file.  Right now, it does not sound like something PDE should implement.

  When doing an export from the IDE (invoking PDE Build), we provide the list of repositories from your target platform.  This allows PDE build to use metadata from those repositories instead of generating the metadata itself.  Releng builds that use PDE Build can also provide the repositories to see the same performance improvement.  I don't know enough about PDE Build to tell you whether other scripts could access this information.

Comment 4 Curtis Windatt

2011-07-20 09:11:19 EDT

Closing as INVALID.  Improving quick fixes to correct dependency issues is covered by other bugs. I don't see any need to provide a list of repositories that pde build uses.  Simply looking at the current target platform will provide you a concise list of all the locations where plug-ins are being obtained from.