You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Julian Sedding <js...@apache.org> on 2016/12/13 09:02:13 UTC
Allow PaxExam to consume provisioning models
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.
WDYT?
Regards
Julian
[0] https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/test/java/org/apache/sling/i18n/it/ResourceBundleProviderIT.java#L165
[1] https://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.launchpad/8/org.apache.sling.launchpad-8-slingfeature.txt
Re: Allow PaxExam to consume provisioning models
Posted by Oliver Lietz <ap...@oliverlietz.de>.
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 <ro...@apache.org>
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
Re: Allow PaxExam to consume provisioning models
Posted by Julian Sedding <js...@gmail.com>.
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 <ro...@apache.org> 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
>
Re: Allow PaxExam to consume provisioning models
Posted by Robert Munteanu <ro...@apache.org>.
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
Re: Allow PaxExam to consume provisioning models
Posted by Julian Sedding <js...@gmail.com>.
I went ahead and implememnted this idea[0]. The issue also shows a usage sample.
Regards
Julian
[0] https://issues.apache.org/jira/browse/SLING-6473
Re: Allow PaxExam to consume provisioning models
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Tue, Dec 13, 2016 at 10:02 AM, Julian Sedding <js...@apache.org> wrote:
> ...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....
I know we have too many testing tools already, but note that the
Crankstart launcher allows you to create tests driven by provisioning
models. It's used in the contrib/commons/mom/jobs/it module for
example.
-Bertrand
Re: Allow PaxExam to consume provisioning models
Posted by Timothee Maret <tm...@apache.org>.
Hi Julian,
I think this is a great idea. It would increase the integration of modules
by defining common combinations of bundles to test on and simplify the
maintenance significantly (the combination of bundle is sorted out at a
single location).
Regards,
Timothee
2016-12-13 10:02 GMT+01:00 Julian Sedding <js...@apache.org>:
> 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.
>
> WDYT?
>
> Regards
> Julian
>
> [0] https://github.com/apache/sling/blob/trunk/bundles/
> extensions/i18n/src/test/java/org/apache/sling/i18n/it/
> ResourceBundleProviderIT.java#L165
> [1] https://repo1.maven.org/maven2/org/apache/sling/org.
> apache.sling.launchpad/8/org.apache.sling.launchpad-8-slingfeature.txt
>