Karl Pauls created SLING-8214:
---------------------------------
Summary: Provide a way to handle bundles with same symbolic name
but different mvn group/artifact ids
Key: SLING-8214
URL: https://issues.apache.org/jira/browse/SLING-8214
Project: Sling
Issue Type: Improvement
Components: Feature Model
Affects Versions: Feature Model 0.8.0, slingfeature-maven-plugin 0.8.0
Reporter: Karl Pauls
Assignee: David Bosschaert
Fix For: Feature Model 0.8.2, slingfeature-maven-plugin 0.8.2
One of the core concepts of the feature model is to use maven coordinates as
the identity of bundles and resources. That has many benefits as we can use
those ids to look up the artifacts in a given maven repository directly as well
as detecting clashes (or duplicates) without having to look inside the
artifacts themselves.
However, this can cause a problem when we have bundles that have the same
symbolic name but different mvn coordinates e.g., consider a symbolic name of
"org.foo" that is used by two artifacts available as mvn:org.bla:org.foo:0.1.0
and mvn:org.blub:org.foo:0.2.0, respectively.
In such a scenario, the feature model will assume these two are unrelated
bundles while in reality (i.e., in the framework) they will denote the same
bundle as the symbolic name is what counts.
In order to make this work properly without having to look inside the artifacts
we should allow for some extra metadata on bundle (and possibly resource)
entries where one can specify additional maven coordinates as aliases for a
given bundle. That way, when creating a deployment, one is able to cause the
proper clash or deduplication actions by aliasing the clashing mvn coordinates.
As an example consider the two artifacts mentioned above. If we have a feature
A that contains mvn:org.bla:org.foo:0.1.0 and a feature B that contains
mvn:org.blub:org.foo:0.2.0 then, A+B will be happily combined and at runtime
install two bundles with the same symbolic name. With the additional metadata
it would be possible to alias one of the two bundles (or both) to the
respective mvn id of the other causing the normal logic to kick in which
allows to properly handle this case using the appropriated policy options.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
