Hi, I would actually refuse to merge if the same PID occurs. It might be unexpected (and incompatible) if you do transparent merging on the property level. It is just important that it is easy to resolve those conflict without touching the feature, i.e. some force option which enforces merging (where the 2nd configuration overwrites properties from the 1st).
Konrad > On 14. Aug 2019, at 08:23, Carsten Ziegeler <[email protected]> wrote: > > Hi, > > when two features are merged (aggregated), configurations are automatically > merged. Meaning if both features have a configuration for the same PID, the > properties from the second feature are put into the configuration of the > first feature, adding and potentially overwriting values. > > However, for everything else (bundles, framework properties, artifacts) it is > up to the caller of the merge functionality to provide guidance for clashes. > Meaning if both features have the same bundle/artifact in different versions, > then there is no auto merge. Same for framework properties. > > It seems a little bit inconsistent that we're using a different approach for > configurations - and it can lead to unexpected results as well. These might > be rare but I would argue they occur as often as the case of merging features > containing the same bundle in different versions. > > So I think we should not auto merge clashing configurations. The question is > on which level we handle the clash: we can already refuse to merge if the > same PID occurs - or we refuse if the same property within a PID occurs? > > WDYT? > > Regards > Carsten > > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected]
