Hi Robert 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).
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). 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. 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. 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 >
