[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tycho-dev] [discuss] tycho repository layout and metadata format
- From: "Sievers, Jan" <jan.sievers@xxxxxxx>
- Date: Wed, 1 Jun 2011 14:03:33 +0200
- Accept-language: en-US, de-DE
- Acceptlanguage: en-US, de-DE
- Delivered-to: firstname.lastname@example.org
- Thread-index: AcwfrUa+7HuWFREHQFGmjuSL2MKyVwAAp/Sw
- Thread-topic: [tycho-dev] [discuss] tycho repository layout and metadata format
>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.