You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2019/08/14 06:23:33 UTC
[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
cziegeler@apache.org
Re: [Features] Merging Configurations
Posted by Radu Cotescu <ra...@apache.org>.
+1
> On 14 Aug 2019, at 08:39, Konrad Windszus <ko...@gmx.de> 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
Posted by Karl Pauls <ka...@gmail.com>.
On Wednesday, August 14, 2019, Konrad Windszus <ko...@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 <cz...@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
> > cziegeler@apache.org
>
>
--
Karl Pauls
karlpauls@gmail.com
Re: [Features] Merging Configurations
Posted by Konrad Windszus <ko...@gmx.de>.
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 <cz...@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
> cziegeler@apache.org