You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Oliver Lietz <ap...@oliverlietz.de> on 2016/07/19 16:53:29 UTC
New module Sling Testing PaxExam
hi all,
I've added a new module org.apache.sling.testing.paxexam in trunk/testing
recently. It provides Sling's Launchpad Karaf Features as Options for Pax
Exam (without Karaf) to setup a Sling instance with less boilerplate code:
* allows to run ITs in the same module (with the build artifact under test)
* allows using different versions in build and tests
* allows overriding of versions
Setting up a Sling Launchpad with some additional "Features":
protected static Option launchpad(final String workingDirectory) {
final int httpPort = findFreePort();
final String slingHome = String.format("%s/sling", workingDirectory);
final String repositoryHome = String.format("%s/repository", slingHome);
final String localIndexDir = String.format("%s/index", repositoryHome);
return composite(
slingJcrOak(),
slingLaunchpadOak(),
slingExtensionI18n(),
slingExtensionModels(),
slingScriptingJsp(),
newConfiguration("org.apache.felix.http")
.put("org.osgi.service.http.port", httpPort)
.asOption(),
newConfiguration("org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService")
.put("repository.home", repositoryHome)
.put("name", "Default NodeStore")
.asOption(),
newConfiguration("org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService")
.put("localIndexDir", localIndexDir)
.asOption(),
mavenBundle().groupId("org.apache.jackrabbit").artifactId("oak-
segment").version(SlingOptions.versionResolver)
);
}
For a complete example see tests in Scripting Thymeleaf. I will cut a first
release when Sling Oak Server 1.1 is available. Any feedback is welcome.
Regards,
O.
Re: New module Sling Testing PaxExam
Posted by Robert Munteanu <ro...@apache.org>.
On Thu, 2016-07-28 at 11:31 +0200, Oliver Lietz wrote:
> On Monday 25 July 2016 15:02:33 Robert Munteanu wrote:
> [...]
> >
> > Looks good, thank you! If I get one more nitpick :-) it would be
> > asking
> > to include the oak-segment bundle declaration in the method that
> > configures it ( slingLaunchpadOakTarConfiguration ). If I invoke
> > that
> > method it's clear that I want the oak-segment bundle included as
> > well.
>
> SLING-5893:
> �
> ����protected Option launchpad() {
> ��������final int httpPort = findFreePort();
> ��������final String workingDirectory = workingDirectory();
> ��������return composite(
> ������������slingLaunchpadOakTar(workingDirectory, httpPort),
> ������������slingExtensionI18n(),
> ������������slingExtensionModels(),
> ������������slingScriptingJsp()
> ��������);
> ����}
>
Looks good, thanks for adding these!
Robert
> �
> >
> > I've also filed a couple of enhancement requests based on what I
> > have
> > seen in other modules - basically boilerplate we copy/paste between
> > @Configuration methods.
>
> See my comments in these issues.
>
> >
> > Other than that, it's not 100% clear to me why, but it seems that
> > there
> > isn't a 'good' Servlet API bundle included in the current
> > SlingOptions
> > class. There is the geronimo specs Jar, but IIUC it's for version
> > 3.0
> > only and we use 3.1 already in some place.
> >
> > I've solved this by adding�
> >
> > �
> > mavenBundle().groupId("org.apache.felix").artifactId("org.apache.fe
> > li
> > x.http.servlet-api").version("1.1.2")
> >
> > to the build.
>
> See r1753994 and r1754021.
>
> Thanks for feedback, Robert. Much appreciated!
>
> Regards,
> O.
>
> >
> > Thanks,
> >
> > Robert
>
Re: New module Sling Testing PaxExam
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Monday 25 July 2016 15:02:33 Robert Munteanu wrote:
[...]
> Looks good, thank you! If I get one more nitpick :-) it would be asking
> to include the oak-segment bundle declaration in the method that
> configures it ( slingLaunchpadOakTarConfiguration ). If I invoke that
> method it's clear that I want the oak-segment bundle included as well.
SLING-5893:
protected Option launchpad() {
final int httpPort = findFreePort();
final String workingDirectory = workingDirectory();
return composite(
slingLaunchpadOakTar(workingDirectory, httpPort),
slingExtensionI18n(),
slingExtensionModels(),
slingScriptingJsp()
);
}
> I've also filed a couple of enhancement requests based on what I have
> seen in other modules - basically boilerplate we copy/paste between
> @Configuration methods.
See my comments in these issues.
> Other than that, it's not 100% clear to me why, but it seems that there
> isn't a 'good' Servlet API bundle included in the current SlingOptions
> class. There is the geronimo specs Jar, but IIUC it's for version 3.0
> only and we use 3.1 already in some place.
>
> I've solved this by adding
>
> mavenBundle().groupId("org.apache.felix").artifactId("org.apache.feli
> x.http.servlet-api").version("1.1.2")
>
> to the build.
See r1753994 and r1754021.
Thanks for feedback, Robert. Much appreciated!
Regards,
O.
> Thanks,
>
> Robert
Re: New module Sling Testing PaxExam
Posted by Robert Munteanu <ro...@apache.org>.
On Fri, 2016-07-22 at 19:53 +0200, Oliver Lietz wrote:
> On Thursday 21 July 2016 19:06:37 Robert Munteanu wrote:
> > On Thu, 2016-07-21 at 13:59 +0200, Oliver Lietz wrote:
> > > On Wednesday 20 July 2016 17:24:15 Robert Munteanu wrote:
> [...]
> > > That can be done always by editing SlingVersionResolver.java
> > > directly.
> > > Using feature.xml should ensure (tests in bootstrap) that all
> > > bundles
> > > are�
> > > compatible (form a runnable Sling instance) and updates don't
> > > have to
> > > be done�
> > > twice.
> >
> > Right, I think that's the toughest part - making sure the bundle
> > versions
> > are in sync.
> >
> > Also, a couple of suggestions related to further reducing the
> > boilerplate.
> >
> > 1. Simpler HTTP port detection
> >
> > If no http port is specified we can just pick a random one and log
> > it, or
> > otherwise we have
> >
> > ���withHttpPort(int port);
> >
> > method which takes a specified HTTP port.
> >
> > 2. Automatic management of the working directory
> >
> > In the event ITs we manually manage:
> >
> > - the working directory
> > - sling.home
> > - repository.home ( or alternatively the OSGi configs for the
> > segment node
> > store and the lucene index provider )
> >
> > Could we also move these inside the module? I don't think we even
> > need a
> > config option here, just auto-manage them.
> >
> > If you agree, I'll file enhancement requests.
>
> See my latest commits in Testing PaxExam (SLING-5893 and SLING-5894)
> and�
> Scripting Thymeleaf. There is now test support (similar to what I've
> done for�
> Launchpad Karaf ITs) and a default configuration. I've tried to find
> the�
> perfect balance between automation and adaptability.
>
> Let me know if it works for you.
Looks good, thank you! If I get one more nitpick :-) it would be asking
to include the oak-segment bundle declaration in the method that
configures it (�slingLaunchpadOakTarConfiguration ). If I invoke that
method it's clear that I want the oak-segment bundle included as well.
I've also filed a couple of enhancement requests based on what I have
seen in other modules - basically boilerplate we copy/paste between
@Configuration methods.
Other than that, it's not 100% clear to me why, but it seems that there
isn't a 'good' Servlet API bundle included in the current SlingOptions
class. There is the geronimo specs Jar, but IIUC it's for version 3.0
only and we use 3.1 already in some place.
I've solved this by adding�
��mavenBundle().groupId("org.apache.felix").artifactId("org.apache.feli
x.http.servlet-api").version("1.1.2")
to the build.
Thanks,
Robert
Re: New module Sling Testing PaxExam
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Thursday 21 July 2016 19:06:37 Robert Munteanu wrote:
> On Thu, 2016-07-21 at 13:59 +0200, Oliver Lietz wrote:
> > On Wednesday 20 July 2016 17:24:15 Robert Munteanu wrote:
[...]
> > That can be done always by editing SlingVersionResolver.java
> > directly.
> > Using feature.xml should ensure (tests in bootstrap) that all bundles
> > are
> > compatible (form a runnable Sling instance) and updates don't have to
> > be done
> > twice.
>
> Right, I think that's the toughest part - making sure the bundle versions
> are in sync.
>
> Also, a couple of suggestions related to further reducing the boilerplate.
>
> 1. Simpler HTTP port detection
>
> If no http port is specified we can just pick a random one and log it, or
> otherwise we have
>
> withHttpPort(int port);
>
> method which takes a specified HTTP port.
>
> 2. Automatic management of the working directory
>
> In the event ITs we manually manage:
>
> - the working directory
> - sling.home
> - repository.home ( or alternatively the OSGi configs for the segment node
> store and the lucene index provider )
>
> Could we also move these inside the module? I don't think we even need a
> config option here, just auto-manage them.
>
> If you agree, I'll file enhancement requests.
See my latest commits in Testing PaxExam (SLING-5893 and SLING-5894) and
Scripting Thymeleaf. There is now test support (similar to what I've done for
Launchpad Karaf ITs) and a default configuration. I've tried to find the
perfect balance between automation and adaptability.
Let me know if it works for you.
Regards,
O.
> Thanks,
>
> Robert
[...]
Re: New module Sling Testing PaxExam
Posted by Robert Munteanu <ro...@apache.org>.
On Thu, 2016-07-21 at 13:59 +0200, Oliver Lietz wrote:
> On Wednesday 20 July 2016 17:24:15 Robert Munteanu wrote:
> [...]
> > > Sure, the templates used to generate both Java files from
> > > Launchpad
> > > Karaf�
> > > Features are already in SVN under resources.
> > >
> > > The code (some Java classes running from my IDE) reading the
> > > feature.xml and�
> > > generating the Java sources needs some cleanup and optimization.
> > > The
> > > same code�
> > > is also used to query Maven Central and to update dependencies in
> > > feature.xml�
> > > \u2013 the paths to features and templates are hard-coded and guava is
> > > "fixed".
> > > I will come up with some kind of "application", fatjar or similar
> > > for
> > > easy�
> > > usage.
> >
> > OK.
> >
> > IMO it does not have to be fully automated and fool-proof, but it
> > should be possible for anyone to perform a version update.
>
> That can be done always by editing SlingVersionResolver.java
> directly.
> Using feature.xml should ensure (tests in bootstrap) that all bundles
> are�
> compatible (form a runnable Sling instance) and updates don't have to
> be done�
> twice.
Right, I think that's the toughest part - making sure the bundle versions are in sync.
Also, a couple of suggestions related to further reducing the boilerplate.
1. Simpler HTTP port detection
If no http port is specified we can just pick a random one and log it, or otherwise we have
withHttpPort(int port);
method which takes a specified HTTP port.
2. Automatic management of the working directory
In the event ITs we manually manage:
- the working directory
- sling.home
- repository.home ( or alternatively the OSGi configs for the segment node store and the lucene index provider )
Could we also move these inside the module? I don't think we even need a config option here, just auto-manage them.
If you agree, I'll file enhancement requests.
Thanks,
Robert
>
> O.
>
> [...]
>
Re: New module Sling Testing PaxExam
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Wednesday 20 July 2016 17:24:15 Robert Munteanu wrote:
[...]
> > Sure, the templates used to generate both Java files from Launchpad
> > Karaf
> > Features are already in SVN under resources.
> >
> > The code (some Java classes running from my IDE) reading the
> > feature.xml and
> > generating the Java sources needs some cleanup and optimization. The
> > same code
> > is also used to query Maven Central and to update dependencies in
> > feature.xml
> > – the paths to features and templates are hard-coded and guava is
> > "fixed".
> > I will come up with some kind of "application", fatjar or similar for
> > easy
> > usage.
>
> OK.
>
> IMO it does not have to be fully automated and fool-proof, but it
> should be possible for anyone to perform a version update.
That can be done always by editing SlingVersionResolver.java directly.
Using feature.xml should ensure (tests in bootstrap) that all bundles are
compatible (form a runnable Sling instance) and updates don't have to be done
twice.
O.
[...]
Re: New module Sling Testing PaxExam
Posted by Robert Munteanu <ro...@apache.org>.
On Wed, 2016-07-20 at 14:47 +0200, Oliver Lietz wrote:
> On Wednesday 20 July 2016 15:00:26 Robert Munteanu wrote:
> > Hi,
> >
> > On Tue, 2016-07-19 at 18:53 +0200, Oliver Lietz wrote:
> > > hi all,
> > >
> > > I've added a new module org.apache.sling.testing.paxexam in
> > > trunk/testing�
> > > recently. It provides Sling's Launchpad Karaf Features as
> > > Option\ufeffs
> > > for Pax�
> > > Exam (without Karaf) to setup a Sling instance with less
> > > boilerplate
> > > code:
> > >
> > > * allows to run ITs in the same module (with the build artifact
> > > under
> > > test)
> > > * allows using different versions in build and tests
> > > * allows overriding of versions
> >
> > (snip)
> >
> > I really like this from an API point of view, as it makes it much
> > simpler to configure tests.
> >
> > A couple of thoughts:
> >
> > - there are notes about code being auto-generated. Can you add
> > instructions and/or scripts to SVN, allowing other to update as
> > well?
>
> Sure, the templates used to generate both Java files from Launchpad
> Karaf�
> Features are already in SVN under resources.
>
> The code (some Java classes running from my IDE) reading the
> feature.xml and�
> generating the Java sources needs some cleanup and optimization. The
> same code�
> is also used to query Maven Central and to update dependencies in
> feature.xml�
> \u2013 the paths to features and templates are hard-coded and guava is
> "fixed".
> I will come up with some kind of "application", fatjar or similar for
> easy�
> usage.
OK.
IMO it does not have to be fully automated and fool-proof, but it
should be possible for anyone to perform a version update.
>
> > - we still reference snapshots. I know this is how we currently
> > keep
> > the launchpad, but we can't ship a release with tests pointing to
> > SNAPSHOT versions. Not sure what the best way to fix it is though.
>
> The only essential bundle is Oak Server, all other snapshots will be
> removed�
> in the near future to not block a first release of Launchpad Karaf
> any longer.
> I've released a bunch of bundles in the past days to finally get rid
> of the�
> snapshots and will not let any new snapshots in. Hence Testing
> PaxExam will�
> not use snapshots. If you need snapshots for testing you can override
> the�
> version using SlingVersionResolver.
Sounds good.
Thanks,
Robert
Re: New module Sling Testing PaxExam
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Wednesday 20 July 2016 15:00:26 Robert Munteanu wrote:
> Hi,
>
> On Tue, 2016-07-19 at 18:53 +0200, Oliver Lietz wrote:
> > hi all,
> >
> > I've added a new module org.apache.sling.testing.paxexam in
> > trunk/testing
> > recently. It provides Sling's Launchpad Karaf Features as Options
> > for Pax
> > Exam (without Karaf) to setup a Sling instance with less boilerplate
> > code:
> >
> > * allows to run ITs in the same module (with the build artifact under
> > test)
> > * allows using different versions in build and tests
> > * allows overriding of versions
>
> (snip)
>
> I really like this from an API point of view, as it makes it much
> simpler to configure tests.
>
> A couple of thoughts:
>
> - there are notes about code being auto-generated. Can you add
> instructions and/or scripts to SVN, allowing other to update as well?
Sure, the templates used to generate both Java files from Launchpad Karaf
Features are already in SVN under resources.
The code (some Java classes running from my IDE) reading the feature.xml and
generating the Java sources needs some cleanup and optimization. The same code
is also used to query Maven Central and to update dependencies in feature.xml
– the paths to features and templates are hard-coded and guava is "fixed".
I will come up with some kind of "application", fatjar or similar for easy
usage.
> - we still reference snapshots. I know this is how we currently keep
> the launchpad, but we can't ship a release with tests pointing to
> SNAPSHOT versions. Not sure what the best way to fix it is though.
The only essential bundle is Oak Server, all other snapshots will be removed
in the near future to not block a first release of Launchpad Karaf any longer.
I've released a bunch of bundles in the past days to finally get rid of the
snapshots and will not let any new snapshots in. Hence Testing PaxExam will
not use snapshots. If you need snapshots for testing you can override the
version using SlingVersionResolver.
> I've also tried using this for moving the Sling ITs to Oak but failed,
> let's continue that discussion in SLING-5870.
Will have a look.
Regards,
O.
> Robert
Re: New module Sling Testing PaxExam
Posted by Robert Munteanu <ro...@apache.org>.
Hi,
On Tue, 2016-07-19 at 18:53 +0200, Oliver Lietz wrote:
> hi all,
>
> I've added a new module org.apache.sling.testing.paxexam in
> trunk/testing�
> recently. It provides Sling's Launchpad Karaf Features as Option\ufeffs
> for Pax�
> Exam (without Karaf) to setup a Sling instance with less boilerplate
> code:
>
> * allows to run ITs in the same module (with the build artifact under
> test)
> * allows using different versions in build and tests
> * allows overriding of versions
(snip)
I really like this from an API point of view, as it makes it much
simpler to configure tests.
A couple of thoughts:
- there are notes about code being auto-generated. Can you add
instructions and/or scripts to SVN, allowing other to update as well?
- we still reference snapshots. I know this is how we currently keep
the launchpad, but we can't ship a release with tests pointing to
SNAPSHOT versions. Not sure what the best way to fix it is though.
I've also tried using this for moving the Sling ITs to Oak but failed,
let's continue that discussion in SLING-5870.
Robert
Re: New module Sling Testing PaxExam
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Tuesday 19 July 2016 18:53:29 Oliver Lietz wrote:
> hi all,
>
> I've added a new module org.apache.sling.testing.paxexam in trunk/testing
> recently. It provides Sling's Launchpad Karaf Features as Options for Pax
> Exam (without Karaf) to setup a Sling instance with less boilerplate code:
>
> * allows to run ITs in the same module (with the build artifact under test)
> * allows using different versions in build and tests
> * allows overriding of versions
>
> Setting up a Sling Launchpad with some additional "Features":
Default configurations are now available as Options by using
slingLaunchpadOakTarConfiguration(String, int) and baseConfiguration() from
TestSupport:
protected Option launchpad() {
final int httpPort = findFreePort();
final String workingDirectory = workingDirectory();
return composite(
slingLaunchpadOakTarConfiguration(workingDirectory, httpPort),
slingJcrOak(),
slingLaunchpadOak(),
slingExtensionI18n(),
slingExtensionModels(),
slingScriptingJsp(),
mavenBundle().groupId("org.apache.jackrabbit").artifactId("oak-
segment").version(SlingOptions.versionResolver)
);
}
Regards,
O.