Re: [Features] Merging Configurations
+1 > On 14 Aug 2019, at 08:39, Konrad Windszus wrote: > > 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).
Re: [Features] Merging Configurations
On Wednesday, August 14, 2019, Konrad Windszus 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 > 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 > > cziege...@apache.org > > -- Karl Pauls karlpa...@gmail.com
Re: [Features] Merging Configurations
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 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 > cziege...@apache.org
[Features] Merging Configurations
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 cziege...@apache.org
