Hi Oliver, 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.
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. 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#features > > 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/tree/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/master/src/test/java/org/apache/sling/testing/paxexam/it/tests> > 3. ("launchpad") > 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 > <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/ma > > in/features [2] > > https://github.com/apache/sling-org-apache-sling-testing-paxexam > > > > >
