You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "David Bosschaert (JIRA)" <ji...@apache.org> on 2019/01/29 11:50:00 UTC
[jira] [Commented] (SLING-8251) Support checking dependencies for
content packages
[ https://issues.apache.org/jira/browse/SLING-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16754918#comment-16754918 ]
David Bosschaert commented on SLING-8251:
-----------------------------------------
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 (or possibly multiple namespaces). Maybe we can call it {{org.apache.sling.content}}. Then it could have different attributes depending on what you want to express, something like:
||attribute||description||
|name|reference content package by name |
|version|reference content package by version |
|path|reference content resources inside the content package|
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;name=foo,org.apache.sling.content:version=1.2.0
{code}
or provide a capability with resources:
{code:java}
Provide-Capability:
org.apache.sling.content;path=/content/foo-path,
org.apache.sling.content;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)