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)