On Wednesday, August 14, 2019, Konrad Windszus <konra...@gmx.de> 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 <cziege...@apache.org>
> 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

Reply via email to