sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Bosschaert (JIRA)" <>
Subject [jira] [Commented] (SLING-8104) Avoid magic when merging features
Date Wed, 14 Nov 2018 18:39:00 GMT


David Bosschaert commented on SLING-8104:

Maybe we could have a mechanism as follows: if more than one feature provides a certain artifact
(bundle) then, if both are _not_ exactly the same some configuration needs to be present to
do the resolution. Otherwise the merge will fail.

For example maybe some configuration in the creation of the aggregate in the slingfeature-maven-plugin,
like this:
    <>1.2.3</> <!-- use a specific version
    <>HIGHEST(1.*)</> <!-- use the highest
version available with a major version of 1.x -->
    <>HIGHEST</> <!-- use the highest version
(what it does now) -->
    <>ALL</> <!-- keep all versions -->
I think the mechanism should work on artifact gav's rather than bsn/version since the merger
only knows about artifacts. This also makes the mechanism more generic.

Just an initial proposal, would be more than happy with improvement suggestions. Note that
the launcher will also need a mechanism to specify this.

> Avoid magic when merging features
> ---------------------------------
>                 Key: SLING-8104
>                 URL:
>             Project: Sling
>          Issue Type: Improvement
>          Components: Feature Model
>            Reporter: Carsten Ziegeler
>            Priority: Blocker
>             Fix For: slingfeature-maven-plugin 1.0.0, Feature Model 0.2.2
> Currently when features are merged a simple algorithm is applied which just picks the
highest version based on the bundle version. However this version might not have no meaning
at all and might not really reflect what has changed inside the bundle.
> Especially when there is a major version change, this approach seems to be clearly wrong
> But in the end, picking a single version is magic.
> While the problem could probably be solved by using something like a resolver and figure
out if just one version is enough or if both versions are needed, without a resolver there
is no way to figure this out.
> Therefore we should provide a similar way as we do for variables at the moment: if there
is a clash the caller needs to provide context on what to choose.

This message was sent by Atlassian JIRA

View raw message