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

Bug 340276

Summary: [target] Make resolution mode more granular for software sites
Product: [Eclipse Project] PDE Reporter: Gunnar Wagenknecht <gunnar>
Component: UIAssignee: PDE-UI-Inbox <pde-ui-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: enhancement    
Priority: P3 CC: jeffmcaffer, rsternberg
Version: 3.7   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard: stalebug

Description Gunnar Wagenknecht CLA 2011-03-17 03:34:35 EDT
3.7M6

It would be nice if the setting "Include required dependencies" could be checked on a per item base instead of globally for the whole target platform.

For example, the launcher/executables features must usually be fetched including all platform fragments. But for a majority of entries it would be easier to work with "Include required dependencies".

This is somewhat related to the require vs. include discussion when composing features.

As an alternative, it would also be sufficient to fetch *all* available platform fragments even when "Include required dependencies" is checked.
Comment 1 Jeff McAffer CLA 2011-03-17 14:08:56 EDT
yup. would be nice but there are a lot of impacts of doing that.  As it is, each target maps to one profile.  That profile can only be resolved one way-- either with the planner or the slicer.  If you use the planner you cannot say you want all platforms since the planner is trying to make a very precise, runnable setup.

If we switch to use one profile per software site in the target then they can be resolved independently and the various switches can be flipped independently.  The target may then end up being inconsistent with conflicting content, unnecessary multiple versions, ...

Perahps there is a middle ground where we use the slicer but a various points run the planner to find missing things and make it easy to get them.  This would have the convenience of "just get everything I need" and the flexibility of "get all platforms", ...
Comment 2 Gunnar Wagenknecht CLA 2011-03-17 15:30:53 EDT
(In reply to comment #1)
> yup. would be nice but there are a lot of impacts of doing that.  As it is,
> each target maps to one profile.  That profile can only be resolved one way--
> either with the planner or the slicer. 

That's what I figured.

> [...] unnecessary multiple versions, ...

I can't use the planner and I do have multiple versions in my target. That's very annoying. 

> Perahps there is a middle ground where we use the slicer but a various points
> run the planner to find missing things and make it easy to get them.  This
> would have the convenience of "just get everything I need" and the flexibility
> of "get all platforms", ...

From a usability point of view it would be great if a user wouldn't have to deal with checking boxes. Just hook the target and you are done.
Comment 3 Jeff McAffer CLA 2011-03-17 15:41:37 EDT
(In reply to comment #2)
> I can't use the planner and I do have multiple versions in my target. That's
> very annoying. 

You can have multiple versions but only if that is explicitly required/allowed by the things you are adding to the target.  The planner is the full on resolver that is used in p2.  It is attempting to find the minimal set of bundles that meet the expressed requirements for a given platform as it would if were installing into normal executable profile.

I almost never use the planner (include required) for managing targets in the runtime context.  That is one reason we have the Target Components elements in the release repos.  You can just "get" Equinox/ECF/RAP/Virgo/... and then setup a runtime config based on the features that that brought down.

Anyway, yes, having this be as easy as possible would be good.
Comment 4 Lars Vogel CLA 2019-11-08 04:39:19 EST
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

If the bug is still relevant please remove the stalebug whiteboard tag.