[
https://issues.apache.org/jira/browse/SLING-10339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hans-Peter Stoerr updated SLING-10339:
--------------------------------------
Affects Version/s: (was: Feature Model Content Extension 1.0.10)
JCR Package Init 1.0.2
Description:
I am using the feature model [content deployment
extension|https://github.com/apache/sling-org-apache-sling-feature-extension-content]
to deploy some content packages as a feature using the Sling feature launcher,
since the simple
[ContentPackageHandler|https://github.com/apache/sling-org-apache-sling-feature-launcher/blob/master/src/main/java/org/apache/sling/feature/launcher/impl/extensions/handlers/ContentPackageHandler.java]
of the feature launcher is not able to specify an order in which the
content-packages are installed. However there is a problem with the
FSPackageRegistry.contains that prevented this from working when package
dependencies are specified in the content-packages: these are checked by
ExecutionPlanBuilder as called from
[ExecutionPlanRepoInitializer|https://github.com/apache/sling-org-apache-sling-jcr-packageinit/blob/master/src/main/java/org/apache/sling/jcr/packageinit/impl/ExecutionPlanRepoInitializer.java],
but FSPackageRegistry.contains always returns false since the
FSPackageRegistry isn't initialized yet. I reported that as a jackrabbit vault
bug, but to make that work with the current version of Jackrabbit Vault I
suggest to introduce a workaround: call FSPackageRegistry.packages() before
executing the ExecutionPlan to initialize the FSPackageRegistry.
Please note that this needs changing the unittest since the FSPackageRegistry
cannot be initialized without setting a homeDir. Perhaps you could just use a
Mockito mock instead of an actual FSPackageRegistry. (I could provide a patch
if you tell me how to deal with the unittest issue.)
BTW: it took me quite a while to find out that you can specify an installation
order for the packages with the content deployment extension by specifying the
packages e.g. like that in the feature - it's probably a good idea to mention
that in the org.apache.sling.extension.content README.md:
{code:java}
"content-packages:ARTIFACTS|required": [
{
"id":
"com.composum.platform:composum-platform-commons-package:zip:${composum.platform.version}",
"start-order": "31"
},
{
"id":
"com.composum.platform:composum-platform-cache-package:zip:${composum.platform.version}",
"start-order": "31"
}
]{code}
PS: Another think that took me a while to solve is that the bundles that are
embedded in the packages get the start level 1. (The same thing happens when
you deploy a package with the package manager.) The solution of that was to set
the framework property felix.startlevel.bundle to something like 30 - this
might even go into the starter.
PS 2: another thing that should be mentioned somewhere is that the feature
model content extension has to be in the classpath before the feature launcher
since otherwise the standard feature launcher ContentPackageHandler is used.
was:
I am using the feature model [content deployment
extension|https://github.com/apache/sling-org-apache-sling-feature-extension-content]
to deploy some content packages as a feature using the Sling feature launcher,
since the simple
[ContentPackageHandler|https://github.com/apache/sling-org-apache-sling-feature-launcher/blob/master/src/main/java/org/apache/sling/feature/launcher/impl/extensions/handlers/ContentPackageHandler.java]
of the feature launcher is not able to specify an order in which the
content-packages are installed. However there is a problem with the
FSPackageRegistry.contains that prevented this from working when package
dependencies are specified in the content-packages: these are checked by
ExecutionPlanBuilder, but FSPackageRegistry.contains always returns false since
the FSPackageRegistry isn't initialized yet. I reported that as a jackrabbit
vault bug, but to make that work with the current version of Jackrabbit Vault I
suggest to introduce a workaround: call FSPackageRegistry.packages() before
executing the ExecutionPlan to initialize the FSPackageRegistry.
Please note that this needs changing the unittest since the FSPackageRegistry
cannot be initialized without setting a homeDir. Perhaps you could just use a
Mockito mock instead of an actual FSPackageRegistry. (I could provide a patch
if you tell me how to deal with the unittest issue.)
BTW: it took me quite a while to find out that you can specify an installation
order for the packages with the content deployment extension by specifying the
packages e.g. like that in the feature - it's probably a good idea to mention
that in the README.md:
{code:java}
"content-packages:ARTIFACTS|required": [
{
"id":
"com.composum.platform:composum-platform-commons-package:zip:${composum.platform.version}",
"start-order": "31"
},
{
"id":
"com.composum.platform:composum-platform-cache-package:zip:${composum.platform.version}",
"start-order": "31"
}
]{code}
PS: Another think that took me a while to solve is that the bundles that are
embedded in the packages get the start level 1. (The same thing happens when
you deploy a package with the package manager.) The solution of that was to set
the framework property felix.startlevel.bundle to something like 30 - this
might even go into the starter.
PS 2: another thing that should be mentioned somewhere is that the feature
model content extension has to be in the classpath before the feature launcher
since otherwise the standard feature launcher ContentPackageHandler is used.
Summary: Execution plan failure for JCR Package Init (was:
Execution plan failure for org.apache.sling.extension.content)
> Execution plan failure for JCR Package Init
> -------------------------------------------
>
> Key: SLING-10339
> URL: https://issues.apache.org/jira/browse/SLING-10339
> Project: Sling
> Issue Type: Improvement
> Components: Starter
> Affects Versions: JCR Package Init 1.0.2
> Reporter: Hans-Peter Stoerr
> Priority: Minor
>
> I am using the feature model [content deployment
> extension|https://github.com/apache/sling-org-apache-sling-feature-extension-content]
> to deploy some content packages as a feature using the Sling feature
> launcher, since the simple
> [ContentPackageHandler|https://github.com/apache/sling-org-apache-sling-feature-launcher/blob/master/src/main/java/org/apache/sling/feature/launcher/impl/extensions/handlers/ContentPackageHandler.java]
> of the feature launcher is not able to specify an order in which the
> content-packages are installed. However there is a problem with the
> FSPackageRegistry.contains that prevented this from working when package
> dependencies are specified in the content-packages: these are checked by
> ExecutionPlanBuilder as called from
> [ExecutionPlanRepoInitializer|https://github.com/apache/sling-org-apache-sling-jcr-packageinit/blob/master/src/main/java/org/apache/sling/jcr/packageinit/impl/ExecutionPlanRepoInitializer.java],
> but FSPackageRegistry.contains always returns false since the
> FSPackageRegistry isn't initialized yet. I reported that as a jackrabbit
> vault bug, but to make that work with the current version of Jackrabbit Vault
> I suggest to introduce a workaround: call FSPackageRegistry.packages() before
> executing the ExecutionPlan to initialize the FSPackageRegistry.
> Please note that this needs changing the unittest since the FSPackageRegistry
> cannot be initialized without setting a homeDir. Perhaps you could just use a
> Mockito mock instead of an actual FSPackageRegistry. (I could provide a patch
> if you tell me how to deal with the unittest issue.)
> BTW: it took me quite a while to find out that you can specify an
> installation order for the packages with the content deployment extension by
> specifying the packages e.g. like that in the feature - it's probably a good
> idea to mention that in the org.apache.sling.extension.content README.md:
> {code:java}
> "content-packages:ARTIFACTS|required": [
> {
> "id":
> "com.composum.platform:composum-platform-commons-package:zip:${composum.platform.version}",
> "start-order": "31"
> },
> {
> "id":
> "com.composum.platform:composum-platform-cache-package:zip:${composum.platform.version}",
> "start-order": "31"
> }
> ]{code}
> PS: Another think that took me a while to solve is that the bundles that are
> embedded in the packages get the start level 1. (The same thing happens when
> you deploy a package with the package manager.) The solution of that was to
> set the framework property felix.startlevel.bundle to something like 30 -
> this might even go into the starter.
> PS 2: another thing that should be mentioned somewhere is that the feature
> model content extension has to be in the classpath before the feature
> launcher since otherwise the standard feature launcher ContentPackageHandler
> is used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
