Hans-Peter Stoerr created SLING-10339:
-----------------------------------------

             Summary: Execution plan failure for 
org.apache.sling.extension.content
                 Key: SLING-10339
                 URL: https://issues.apache.org/jira/browse/SLING-10339
             Project: Sling
          Issue Type: Improvement
          Components: Starter
    Affects Versions: Feature Model Content Extension 1.0.10
            Reporter: Hans-Peter Stoerr


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: 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 a start order of 
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.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to