On Wednesday, August 14, 2019, Konrad Windszus <[email protected]> wrote:
> 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) +1 regards, Karl > 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] > > -- Karl Pauls [email protected]
