Hi Oliver, I'm not sure about how a "feature model" feature would express dependencies on other features or whether that is even necessary.
But as an experiment, I just tried to create a simple aggregate feature that contains just the jcr maintenance feature and nothing else. During the build the analyse-features goal processes that incomplete aggregate feature and I get a nice report back (see below) about what packages and capabilities are missing and then I can go look for the features or bundles that would provide those and add them, and repeat that cycle until there are no errors. I guess I'm just saying that it is a nicer error report and fails faster than trying to parse the log files generated during a paxexam test to figure out why it didn't work. And if I go through all the work to create a working aggregate feature model it seems like it would be nice to be able to use that directly in my paxexam integration tests rather than trying to recreate the same configuration in java code. For example, the mvn output may look something like this: ========================================= [INFO] Starting analyzing feature 'experiment:starter:slingosgifeature:jcr_maintenance:1.0.0-SNAPSHOT'... [INFO] - Executing APIs jar properties check [apis-jar]... [INFO] - Executing Bundle Import/Export Check [bundle-packages]... [INFO] - Executing Repoinit Check [repoinit]... [INFO] - Executing Requirements Capabilities check [requirements-capabilities]... [INFO] Analyzing feature 'experiment:starter:slingosgifeature:jcr_maintenance:1.0.0-SNAPSHOT' finished : 0 warnings, 2 errors. [ERROR] org.apache.sling:org.apache.sling.jcr.maintenance:1.0.0: is importing package(s) [org.apache.jackrabbit.oak.api.jmx, org.apache.jackrabbit.oak.commons.jmx, org.slf4j, org.apache.felix.hc.api, javax.jcr.version, org.apache.sling.api.resource, javax.jcr] in start level 20 but no bundle is exporting these for that start level. [ERROR] org.apache.sling:org.apache.sling.jcr.maintenance:1.0.0: Artifact org.apache.sling:org.apache.sling.jcr.maintenance:1.0.0 requires [org.apache.sling.jcr.maintenance/1.0.0] osgi.extender; filter:="(&(osgi.extender=osgi.component)(version>=1.4.0)(!(version>=2.0.0)))" in start level 20 but no artifact is providing a matching capability in this start level. [ERROR] Analyser detected errors on feature 'experiment:starter:slingosgifeature:jcr_maintenance:1.0.0-SNAPSHOT'. See log output for error messages. Regards, -Eric On Mon, Mar 1, 2021 at 2:57 PM Oliver Lietz <[email protected]> wrote: > On Monday, 1 March 2021 18:51:42 CET Eric Norman wrote: > > Hi Oliver, > > Hi Eric, > > > The problem I frequently run into is that the default configurations from > > SlingOptions are almost always providing versions of bundles that are too > > old to use for testing new features. And then at that point it requires > a > > lot of research and trial and error to find a compatible set of bundles > to > > get it to start up properly. This is why I would think the feature > model + > > the build time "analyse-features" goals may be useful in identifying > > configuration troubles earlier and with better error messages when things > > go wrong. > > Feel free to create options for your tests from the feature model. > > > On the other hand with Sling Feature Model there is a big drawback. > There is > > > only a full blown Sling, no fine grained features. > > > > I don't think this is true, you can assemble things in any way you want, > > and in fact the starter already has many feature descriptors published > > under different classifiers that you could reference independently. > > > > But I would agree that the sling starter isn't the best place to define > the > > features. The starter should really just be aggregating features defined > > elsewhere and each feature should be released on its own schedule. The > > recently released sling-org-apache-sling-jcr-maintenance project is a > good > > example of doing something like this as the starter is just referencing > the > > released feature instead of defining everything inside the starter. > > AFAIK by design there is no way to express dependencies in OSGi/Sling > Features. > > You cannot tell from the feature of Sling JCR Maintenance what is required > to > get it up and running. Is Jackrabbit required or even Oak? Which version? > > I haven't looked into the "analyse-features" goal. Does it take > Capabilities/ > Requirements into account? How is it working around the fact that for > several > bundles the meta data is missing? > > If you tell me there is a way to declare and maintain features > automatically – > great! Until now a lot of manual work was required for Sling's Karaf > Features. > > Regards, > O. > > > > Regards > > -Eric > > > > On Mon, Mar 1, 2021 at 2:22 AM Oliver Lietz <[email protected]> > wrote: > > > On Friday, 26 February 2021 18:54:28 CET Bertrand Delacretaz wrote: > > > > Hi, > > > > > > > > On Fri, Feb 26, 2021 at 6:31 PM Eric Norman <[email protected]> > wrote: > > > > > ...Someday, maybe the sling feature model could be used to derive > the > > > > > paxexam configuration so it would be less mysterious and easier to > > > > > debug?.. > > > > > > This can be implemented quite easily but you would need regular > "releases" > > > of > > > Sling Starter or you would have to deal with a moving target. > > > > > > On the other hand with Sling Feature Model there is a big drawback. > There > > > is > > > only a full blown Sling, no fine grained features. > > > > > > The purpose of Sling Testing PaxExam (extending OPS4J Pax *Exam* for > use > > > in > > > Sling project) is described here: > > > > > > > > > > https://sling.apache.org/documentation/development/testing-paxexam.html#fe > > > atures > > > > > > You get well tested sets of bundles (2-3 times) via SlingOptions and > some > > > helpers in TestSupport. > > > > > > Tested bundle sets: > > > 1. (all) > > > > https://github.com/apache/sling-org-apache-sling-karaf-integration-tests/t > > > ree/master/src/test/java/org/apache/sling/karaf/tests/bootstrap 2. > (all) > > > https://github.com/apache/sling-org-apache-sling-testing-paxexam/ > > > tree/master/src/test/java/org/apache/sling/testing/paxexam/it/tests > > > < > https://github.com/apache/sling-org-apache-sling-testing-paxexam/tree/ma > > > ster/src/test/java/org/apache/sling/testing/paxexam/it/tests> 3. > > > ("launchpad") > > > > https://github.com/apache/sling-org-apache-sling-karaf-launchpad-oak-tar-i > > > ntegration-tests/blob/master/src/test/java/org/apache/ > > > sling/karaf/tests/configuration/SlingQuickstartOakTarConfiguration.java > > > < > https://github.com/apache/sling-org-apache-sling-karaf-launchpad-oak-tar > > > > -integration-tests/blob/master/src/test/java/org/apache/sling/karaf/tests/ > > > configuration/SlingQuickstartOakTarConfiguration.java> > > > > > > Let me know if the documentation is unclear and needs to be fixed. > > > > > > O. > > > > > > > That would be great, and in the meantime I suppose the various > > > > versions of the lists of bundles at [1] can help find out about the > > > > right combinations. Assuming those are not defined in [2] already. > > > > > > > > -Bertrand > > > > > > > > [1] > > > > > > > https://github.com/apache/sling-org-apache-sling-starter/tree/master/src/m > > > a > > > > > > > in/features [2] > > > > https://github.com/apache/sling-org-apache-sling-testing-paxexam > > > > >
