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

Bug 331354

Summary: [target] Target editor: Possibility to automatically add all required units explicitly to a location in slicer mode
Product: [Eclipse Project] PDE Reporter: Christian Schubert <chr.schubert>
Component: UIAssignee: PDE-UI-Inbox <pde-ui-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: enhancement    
Priority: P3 CC: curtis.windatt.public, felix.riegger, jeffmcaffer
Version: 3.6.1   
Target Milestone: ---   
Hardware: PC   
OS: Windows Vista   
Whiteboard: stalebug

Description Christian Schubert CLA 2010-11-29 11:36:24 EST 
Build Identifier: 20100917-0705

When using slicer mode it would be nice to be able to calculate all required units and add them explicitly to the related location.
Having all units defined explicitly makes a reproducable build possible.

The list of IUs could be calculated with the planner and e.g. triggered via an 'Add required software' button in the target editor.

Reproducible: Didn't try
Comment 1 Curtis Windatt CLA 2010-12-01 16:29:46 EST 
Can you explain what you are asking for in more detail?

The p2 containers work in one of two modes, slicing or planning.  You are trying to get it to do both?
Comment 2 Christian Schubert CLA 2010-12-02 11:07:06 EST 
The goal is, to have all units (also the transitive dependencies) explicitly listed in the .target file. In that way, the versions of each and every dependency can be fix (control over versions) and the transitive dependencies are available, although slicer mode is used.

This list of units could be generated using the planner in first place.
Comment 3 Jeff McAffer CLA 2010-12-02 11:25:57 EST 
So essentially it would be like the Add Required buttons in other parts of PDE.  It would happen to use the planner to generate a list of root ius. These roots would be features and bundles and potentialy just random configuration IUs.  The container woudl still be in slicer mode though.

This is theoretically possible but raises a number of issues:
- There is a current expectation that the roots in the container are features. As  a result of some of my recent changes that expectation is somewhat reduced but there are likely still issues in the UI workflows.

- To be complete/accurate the target would have to track IUs for things that are not features or bundles. We could filter out non bundle/feature things but I'm not sure that generalizes well.

- If we did not filter then its not clear how/if those non-feature/bundle things should show up in the UI. 

- This would make the target definitions very brittle.  That's fine if they are autogenerated but if people have to maintain them it will become painful.

In the end this is possible but on the surface, not trivial.

Note that another approach here is to manage the metadata.  For example, if you want to capture a particular setup, freeze the metadata and create a target that points at the frozen metadata.  The target might not include any version information at all but rather just point at a particular "version" of the metadata.  You get the same net effect without the bad aftertaste.
Comment 4 Eclipse Webmaster CLA 2019-09-06 16:10:25 EDT 
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.
Comment 5 Julian Honnen CLA 2019-09-09 02:26:52 EDT 
Please remove the stalebug flag, if this issue is still relevant and can be reproduced on the latest release.