Community
Participate
Working Groups
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.
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?
Created attachment 198944 [details] Unsatisfied dependencies
Created attachment 198945 [details] Target definition The target definition points to http://download.eclipse.org/releases/helios
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.
FWIW I've seen something similar, but I haven't had the chance to dive into it yet.
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.
(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.
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?
Created attachment 200126 [details] Possible fix Patch implementing my proposed solution. Needs additional testing before committing.
*** Bug 353409 has been marked as a duplicate of this bug. ***
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.
