On Tuesday 13 December 2016 12:43:14 Julian Sedding wrote: > Hi Robert Hi Julian,
see my comments inline: > Yes, I am aware of the utilities you mention, and they are useful. I > especially like the utility methods that allow installing a group of > bundles that belong together (i.e. that form a feature). In (Sling) Testing PaxExam these features are Sling's Karaf Features, not the ones from Sling's Provisioning Model. More on this difference later. > However, the "dependency-management" (aka SlingVersionResolver[0]) is > based on a hardcoded list of bundle versions (generated from Karaf > features, as you say, in a way that is unknown to me). The "dependency management" is in SlingOptions and the SlingVersionResolver contains the matching versions for these (Pax Exam) Options. It was a design decision keeping options and versions separate for easily overriding or adding versions in _rare_ cases. > This means in > many cases that for this VersionResolver to be useful, it needs to be > kept in sync with the launchpad provisioning model, because that is > de-facto the "single source of truth" regarding the most recent > collection of bundles. The Launchpad provisioning model is *not* the "single source of truth" and lacks important information – but which are in Sling's Karaf Features and you can create features for provisioning model from Sling's Karaf Features (but not the other way round). It contains only a small subset of Sling's bundles and most of the time a lot of bundles are snapshots. The most important flaws of provisioning model are the missing dependency management and its monolithic nature (it's all or nothing). Sling's Karaf Features are kept in sync with latest releases (and so Testing PaxExam) but there was a gap because of Sling using R6 features only available in Karaf 4.1-SNAPSHOT (see thread "Re: svn commit: r1774871 - /sling/trunk/tooling/jenkins/create_jobs.groovy" on this list). I've a small set of Java classes (with some hardcoded paths) running from IDE to update versions in source feature.xml and transforming final feature.xml to SlingOptions and SlingVersionResolver. The "tooling" will be made available when polished and usable by all. > So refactoring or enhancing the SlingVersionResolver to allow loading > a provisioning model into it would be a start. However, the > provisioning model also provides configurations, creates service users > etc. Currently we cannot re-use these definitions, but we have to > duplicate them. The main goal of integrating the provisioning model > would be to avoid this duplication. The problem you try to tackle is already solved by Testing PaxExam. If you choose a feature from SlingOptions you will get all required dependencies *and* configurations. Sling's Karaf Features are backed by integration tests to always provide a stable set of working bundles. That is no longer given by only pulling in versions from provisioning model. Regards, O. > Regards > Julian > > [0] > https://github.com/apache/sling/blob/trunk/testing/org.apache.sling.testing > .paxexam/src/main/java/org/apache/sling/testing/paxexam/SlingVersionResolver > .java > On Tue, Dec 13, 2016 at 12:19 PM, Robert Munteanu <[email protected]> wrote: > > Hi, > > > > On Tue, 2016-12-13 at 10:02 +0100, Julian Sedding wrote: > >> Hi all > >> > >> I looked at a PaxExam-based i18n test yesterday[0]. It was failing > >> due > >> to missing service user + configuration amendment, which was already > >> adjusted for the launchpad. > >> > >> Furthermore noticing the long list of bundles installed into the > >> PaxExam container, I started thinking that it would be very > >> convenient > >> to have a utility that can consume a provisioning file and use the > >> contained information as Pax-Exam-Options during the construction of > >> a > >> test case. This way tests could depend on a released or snapshot > >> version of the launchpad[1], as well as defining their own > >> provisioning model. > >> > >> It may also be helpful to allow re-using the versions of the bundles > >> defined in a provisioning model, but only installing the ones whose > >> grouId+artifactId are explicitly mentioned in the test. > > > > There are some helper utilities for Pax-Exam at [1] and [2] which > > should help make pax-based tests simpler. > > > > > > I think [1] does mostly what you propose, but based on Karaf features > > rather than the provisioning model. > > > > (Not saying that we should do it one way or the other, just pointing > > out existing code) > > > > Robert > > > > [1]: https://github.com/apache/sling/tree/trunk/testing/org.apache.slin > > g.testing.paxexam > > [2]: https://github.com/apache/sling/tree/trunk/testing/sling-pax-util > > > >> WDYT? > >> > >> Regards > >> Julian > >> > >> [0] https://github.com/apache/sling/blob/trunk/bundles/extensions/i18 > >> n/src/test/java/org/apache/sling/i18n/it/ResourceBundleProviderIT.jav > >> a#L165 > >> [1] https://repo1.maven.org/maven2/org/apache/sling/org.apache.sling. > >> launchpad/8/org.apache.sling.launchpad-8-slingfeature.txt
