[
https://issues.apache.org/jira/browse/SLING-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16754918#comment-16754918
]
David Bosschaert edited comment on SLING-8251 at 1/29/19 4:07 PM:
------------------------------------------------------------------
Hi [~rombert], all,
I'm trying to understand the requirements of this issue a little bit better.
I think to work across the other entities in the feature model it would be best
to express these dependencies in terms of OSGi Requirements/Capabilities.
For dependencies on Java Packages this is easy, as there exists already an OSGi
namespace for this. So the Import-Package would translate, just as with OSGi
bundles, into something like this:
{{Require-Capability:
osgi.wiring.package;filter:="(&(osgi.wiring.package=org.apache.sling.somepackage)(version>=1.2.0)(!(version>=2.0.0)))"}}
For dependencies on other content packages, I see that this is currently
typically expressed in terms of the content package name/version. In the
OSGi-world this is considered an anti-pattern (the Require-Bundle model).
However, if this is the model that exists today, then we need to be able to
model that.
Do content packages also support a dependency model based on actual content?
Maybe the script resolver that [~radu.cotescu] worked on in the Sling
whiteboard already has something like this?
In any case, it seems to me that we need to create a new Capability Namespace
for content packages and possibly another one for content resources. Maybe we
can call it {{org.apache.sling.content.package}}. Then it could have different
attributes depending on what you want to express, something like:
||attribute||description||
|group|reference content package by groupID |
|name|reference content package by artifactID |
|version|reference content package by version |
Then a content package could be represented by something like this, for
providing a capability based on name/version:
{code:java}
Provide-Capability:
org.apache.sling.content.package;name=foo;version=1.2.0
{code}
or provide a capability with resources:
{code:java}
Provide-Capability:
org.apache.sling.content.resource;path=/content/foo-path,
org.apache.sling.content.resource;path=/content/bar-path/bar.jsp
{code}
Any further thoughts?
was (Author: bosschaert):
Hi [~rombert], all,
I'm trying to understand the requirements of this issue a little bit better.
I think to work across the other entities in the feature model it would be best
to express these dependencies in terms of OSGi Requirements/Capabilities.
For dependencies on Java Packages this is easy, as there exists already an OSGi
namespace for this. So the Import-Package would translate, just as with OSGi
bundles, into something like this:
{{Require-Capability:
osgi.wiring.package;filter:="(&(osgi.wiring.package=org.apache.sling.somepackage)(version>=1.2.0)(!(version>=2.0.0)))"}}
For dependencies on other content packages, I see that this is currently
typically expressed in terms of the content package name/version. In the
OSGi-world this is considered an anti-pattern (the Require-Bundle model).
However, if this is the model that exists today, then we need to be able to
model that.
Do content packages also support a dependency model based on actual content?
Maybe the script resolver that [~radu.cotescu] worked on in the Sling
whiteboard already has something like this?
In any case, it seems to me that we need to create a new Capability Namespace
for content packages and possibly another one for content resources. Maybe we
can call it {{org.apache.sling.content.package}}. Then it could have different
attributes depending on what you want to express, something like:
||attribute||description||
|group|reference content package by groupID |
|name|reference content package by artifactID |
|version|reference content package by version |
Then a content package could be represented by something like this, for
providing a capability based on name/version:
{code:java}
Provide-Capability:
org.apache.sling.content.package;name=foo,
org.apache.sling.content.package;version=1.2.0
{code}
or provide a capability with resources:
{code:java}
Provide-Capability:
org.apache.sling.content.resource;path=/content/foo-path,
org.apache.sling.content.resource;path=/content/bar-path/bar.jsp
{code}
Any further thoughts?
> Support checking dependencies for content packages
> --------------------------------------------------
>
> Key: SLING-8251
> URL: https://issues.apache.org/jira/browse/SLING-8251
> Project: Sling
> Issue Type: New Feature
> Components: Feature Model
> Reporter: Robert Munteanu
> Assignee: David Bosschaert
> Priority: Major
>
> When including content packages in a feature model there are some
> dependencies that would be great to check at build time. Both of these are
> defined as manifest headers:
> # dependencies to other content pacakges - Content-Package-Dependencies
> # dependencies to java packages - Import-Package (with the same syntax as the
> OSGi bundle Import-Package header ).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
