Niclas, Robert, It sounded to me as if Robert was more interested in a integration testing framework rather than the build tool used to generate the manifest and build the bundle. Please excuse me if I'm wrong here tho.
I just wanted to say that Directory too would like to start using OSGi but the biggest impediment to date is having a good mini/micro integration testing framework to test our components in the container right after the bundle is generated by Maven for that module. We don't want to have to create a foo module then a foo-test module just to integration test since this will lead to a (Maven) module explosion. It would be nice to have a JUnit-ish framework for in situ testing OSGi bundles inside target containers. Like Robert we want to take bundle foo and make sure if it's a library, the classes there in function properly by running some tests that access those classes within the container. If foo bundle exposes a service we'd like to get a handle on that service and start running some tests on it etc. I think such a framework would help increase uptake. Best Regards, Alex On Wed, Jun 4, 2008 at 8:37 AM, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > On Saturday 31 May 2008 15:02, Robert Burrell Donkin wrote: > > over in JAMES, we'd like to OSGi enable our upcoming library releases > > so that they can be used unforked in OSGi environments. the plan is to > > use the maven plugin but we don't have a lot of OSGi experience. so > > i'd like to add some integration tests to check that the libraries > > function ok when used in an OSGi environment. this seems a reasonably > > general requirement and i was wondering about a general integration > > testing micro library to test that a library was correctly enabled. > > Robert, > > I think the first necessary step is to incorporate the so called BND tool > into > your build. If you are using Maven, then there is a plugin available here > to > make it easier. > > BND recursively walks through the classes and figures out what is needed > and > compares that against a "recipe" that you specify. The recipe can either be > explicit (in which case every import has to specified or else an error) or > you use wildcards (less recommended). > The recipe also contains information about which packages should be > Exported, > ignored and kept private. > > With BND it is not too hard to maintain the recipe (typically an external > file), and will lower the initial need for in-container tests. > > Setting it up is easy, if you know what you are doing, so I suggest that > someone here volunteers (Stuart???) to help you out. > > > Cheers > -- > Niclas Hedhman, Software Developer > > I live here; http://tinyurl.com/2qq9er > I work here; http://tinyurl.com/2ymelc > I relax here; http://tinyurl.com/2cgsug >
