Re: [tycho-dev] [discuss] tycho repository layout and metadata format

["Sievers, Jan" <jan.sievers@xxxxxxx>]

see inline.

>How do you plan to define and manage the list?
[...]
>* as a list of IUs that is then fed as p2 resolver input. how do you
>plan to produce and manage the list in this case? target platforms can
>easily have 1000x of IUs, so I don't think it is feasible to manage by
>hand. if the list is initially resolved from some top-level constraints
>(eclipse sdk 3.6.2, wtp 3.0.2, m2e 0.12.1, etc) than re-resolving this
>list for a single dependency change may result in arbitrary large
>changes to the resolution result.

This will need tooling support.

How about starting with a small set of (top-level) features to define the target platform in a file. 
(transitive) feature includes have perfect version matches and using slicer mode this would mean that there is no "wiggle room".

Later when doing a patch, I have to make sure the feature IU list 
is translated into the equivalent fine-grained (bundle) IU list. E.g. the .target editor does this for me if I switch to the "Content" tab (I know the editor is crappy but the point is here that there could be tooling that does the resolution for me).
Now I have control on bundle level.

My main point for having a whitelist for defining the target platform resolution scope is:

If we don't restrict resolution to a whitelist, any bundle with matching Export-Package for one of your Import-Package requirements can ruin your build when deployed on the global repo you resolve against.

I also see that you don't always want to have this strict reproducibility mode, but we should offer it e.g. for release builds.

Regards,
Jan