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

Bug 350772

Summary:

[target] Target Platform Resolution Fails with unsatisfied dependencies in Indigo but works in Helios SR2

Product:

[Eclipse Project] PDE

Reporter:

Urs Breu <login>

Component:

Assignee:

Curtis Windatt <curtis.windatt.public>

Status:

RESOLVED FIXED

QA Contact:

Severity:

major

Priority:

CC:

curtis.windatt.public, gunnar, irbull, jeffmcaffer, pascal, thorsten.vitt

Version:

4.0

Target Milestone:

3.8 M2

Hardware:

All

OS:

All

Whiteboard:

Bug Depends on:

323910

Bug Blocks:

352806

Attachments:

Description	Flags
Unsatisfied dependencies	none
Target definition	none
Possible fix	none

Description Urs Breu

2011-06-30 03:00:42 EDT

Build Identifier: 20110615-0604

I have a working target definition which I use to build an RCP application for win32, linux and macosx. This target definition worked w/o any problems under Helios SR2. However, in Indigo PDE fails to resolve any of the target platform contents because of unsatisfied dependencies. This occurs even though the "Include all environments" option is selected.
I can only get the target platform to resolve if I select "Include required software". However, then I am of course not able to build cross-platform RCP applications...

Reproducible: Always

Steps to Reproduce:
1. Create a new target definition.
2. Add "Eclipse Platform SDK" feature from the Helios Repository
3. Check "Include all environments"
4. Finish

PDE is unable to resolve any plugins because of a bunch of unsatisfied dependencies.
e.g. org.eclipse.rcp.feature.group 3.6.2.r362 to org.eclipses.swt.gtk.aix

If the same thing is done under Helios the target platform resolves fine.

Comment 1 Curtis Windatt

2011-06-30 13:52:31 EDT

Can you provide your target definition?  Does your definition point to publicly accessible sites?  Can you provide the exact error shown in the target definition?

Jeff, any ideas when you can get unsatisfied dependencies when using the slicer?

Comment 2 Urs Breu

2011-07-01 02:35:21 EDT

Created attachment 198944 [details]
Unsatisfied dependencies

Comment 3 Urs Breu

2011-07-01 02:36:01 EDT

Created attachment 198945 [details]
Target definition

The target definition points to http://download.eclipse.org/releases/helios

Comment 4 Curtis Windatt

2011-07-07 16:12:59 EDT

Reproduced using 3.7.  Also double checked that the same target file resolves successfully in 3.6.2, so this is a regression.

It looks like the feature unit requires a number of platform specific fragments that are not available in the repository.  If I turn off the option to include all environments there are no dependency problems and the artifacts are downloaded.

The change is a regression caused by bug 323910 where we started reporting status items that the slicer collected.  The slicer javadoc doesn't specify what kind of statuses it will return in its results.  However, looking at the code it appears to throw errors if an exception occurs and warnings if a dependency is unsatisfied.  I don't want to hide the warnings from the user in case they expect certain content to be there, but not completing the resolve seems too drastic (and the user often has no control over the content of the repository, so they have no ability to solve the dependency issues).

I'm leaning towards just ignoring warnings (but still report errors).  We could also try and check how many IUs the slicer returns, if 0 IUs are returned and there are warnings, that might be a good time to tell the user.  If Jeff, Pascal, Gunnar, or Ian would like to comment, that would be helpful.

Comment 5 Ian Bull

2011-07-07 23:58:39 EDT

FWIW I've seen something similar, but I haven't had the chance to dive into it yet.

Comment 6 Gunnar Wagenknecht

2011-07-08 01:36:12 EDT

I also agree that warnings should not prevent a target platform from resolving. 

However, I think it would be nice if they could still be presented to a user in some way. But that extended reporting (somthing like an overall status) sounds more like an additional request/feature.

Comment 7 Curtis Windatt

2011-07-11 16:29:29 EDT

(In reply to comment #6)
> I also agree that warnings should not prevent a target platform from resolving. 
> 
> However, I think it would be nice if they could still be presented to a user in
> some way. But that extended reporting (somthing like an overall status) sounds
> more like an additional request/feature.

I suspect that showing the warnings anywhere in the target UI will be seen as clutter.  Tracing options (bug 227238) would be one alternative, but that will probably not happen for 3.8.  For 3.8, showing errors always and warnings only if there are 0 plug-ins seems like a reasonable compromise.

Comment 8 Urs Breu

2011-07-20 06:49:18 EDT

Is it even possible to create a minimal target definition for multiple environments in Indigo with this bug present?

Which repositories would I have to add in order to satisfy the aforementioned dependencies?

Comment 9 Curtis Windatt

2011-07-21 17:20:44 EDT

Created attachment 200126 [details]
Possible fix

Patch implementing my proposed solution.  Needs additional testing before committing.

Comment 10 Curtis Windatt

2011-08-02 08:43:19 EDT

*** Bug 353409 has been marked as a duplicate of this bug. ***

Comment 11 Curtis Windatt

2011-08-12 15:06:03 EDT

Applied the fix to HEAD. The attached patch has one unecessary change to reduce the ticks assigned to one task (was 50 now 40).  This was originally because I was doing an additional query, but some refactoring lead to its removal.