Thanks for the quick response, Toni. So just to clarify, the issue is that we need to tweak the import and export packages of the bundle context in which the test logic actually runs.
This requirement comes about from the way CXF uses spring. Basically the upshot is that we need add some packages to the import and export packages, that wouldn't be obvious to a tool like BND. For example the way CXF loads its "extensions" from spring configs under META-INF/cxf means we have to add META-INF.cxf to the Import-Packages. So would the "tiny bundle" idea actually address this requirement - specifically, would the Junit testcase logic run within the scope of this tiny bundle? Cheers, Eoghan 2009/7/13 Toni Menzel <[email protected]>: > On 7/13/09, Eoghan Glynn <[email protected]> wrote: >> Folks, >> >> I've been looking at cutting SMX4 features & NMR over to Karaf. >> >> One issue I've come across is that the features & NMR integration >> tests are based on the old SMX4 kernel AbstractIntegrationTest, which >> is itself a thin layer over spring-osgi-test framework. >> >> Now in Karaf-land, this AbstractIntegrationTest has been rebased on >> Pax-Exam. I'm new to Pax-Exam, so maybe I'm missing something, but I >> can't see an analogue for the flexibility that spring-osgi-test gives >> in terms of manipulating the manifest for the test bundle created >> on-the-fly. We need this mechanism in the feature case for example to >> ensure that a bunch of CXF packages are present on the Export-Packages >> list. > > Pax Exam's Test Bundles (we call them test probes) are - as of 1.0 - > fully auto mantained by pax exam. This means, you are not in control > of the manifest. > This has been stated often on mailinglists and is not really a > shortcoming but a definition of tests you can do with pax exam: You > test probe is just "orchestrating" the real bundles. This also ensures > you never come to the idea to really use the probe to contain real > logic you better want to have in a bundle you mantain yourself. > > Every bundle that is more than this orchestration (or see it as a test > starting point, the test activation bundle, if you want another > terminology) should be fully in your control. This means: treat that > as a real bundle. > > However, sometimes you really need "tiny bundles" that fill a gap, > that just exist to test a very certain concern - in cxf and can really > think of this very well. > Given this, you don't want to set up a full maven-bundle-plugin > project for each of those tiny bundles, .. well there is a project > called TinyBundles (http://wiki.ops4j.org/display/PAXSB/Tinybundles) > that i started for exactly this concern. > With this, you can create bundles (they don't have to be tiny..) on > the fly like so: > newBundle() > .addClass( MyFirstActivator.class ) > .addClass( HelloWorld.class ) > .addClass( HelloWorldImpl.class ) > .prepare( > withBnd() > .set( Constants.BUNDLE_SYMBOLICNAME, "MyFirstTinyBundle" ) > .set( Constants.EXPORT_PACKAGE, > "org.ops4j.pax.tinybundles.demo" ) > .set( Constants.IMPORT_PACKAGE, > "org.ops4j.pax.tinybundles.demo" ) > .set( Constants.BUNDLE_ACTIVATOR, > MyFirstActivator.class.getName() ) > ).build( asStream() ); > > In this case, contents are pulled out of the current classpath (see > addClass) and the manifest is constructed by bnd with the ability to > set bnd directives. > > The output of this construct is an InputStream that you can use to > install inside your test. > This construct is very flexible and for sure needs more examples. > If this is something of interest i will add some asap. > Deployment Packages can be constructed like this too using > Tinybundles. But this has not been released yet (just in svn version). > > Let me know. > >> >> So I'm toying with the option of bringing the old kernel >> AbstractIntegrationTest stuff into features, while re-basing the NMR >> tests on the new Karaf Pax-Exam pattern. >> >> The NMR tests don't seem to need any jiggery-pokery on the manifest, >> so they should be OK to move across. Though the Karaf >> AbstractIntegrationTest isn't really set up for sharing, as its >> current stuck in the same module as some actual concrete tests. So >> this would probably need to be moved to a separate module if its going >> to be reused by the SMX codebases. In fact, it doesn't even seem to be >> built at the moment, as the itests module is excluded from the >> top-level pom[1]. >> >> Any thoughts or input on either of the above points? >> >> Of course, I'd be delighted if someone pipes up with an approach for >> manifest-manipulation with Pax-Exam, which would mean we could drop >> the whole spring-osgi-test thing. > Would love to see it ;) For sure, if there is *enough evidence* to add > a "manually change bnd instructions"-feature, we can simply add this > to exam. > >> >> Cheers, >> Eoghan >> >> [1] http://svn.apache.org/repos/asf/felix/trunk/karaf/pom.xml >> > > > -- > Toni Menzel > Independent Software Developer > Professional Profile: http://okidokiteam.com > [email protected] > http://www.ops4j.org - New Energy for OSS Communities - Open > Participation Software. >
