sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Bosschaert (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SLING-8251) Support checking dependencies for content packages
Date Tue, 29 Jan 2019 14:43:00 GMT

    [ 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 2:42 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,
 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? 


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
(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)

Mime
View raw message