Guillaume Nodet wrote:
Btw, here is an example of such an osgi integration test:
   
http://svn.apache.org/repos/asf/servicemix/smx4/nmr/trunk/jbi/itests/src/test/java/org/apache/servicemix/jbi/IntegrationTest.java


Hi guys,

thanks for pointing out Spring-DM integration testing framework.
There is also a screencast showing its usage on the Spring-DM home page:
http://www.springframework.org/osgi/demos

Hopefully, you'll find it useful.

If you want to find out more or have any questions, feel free to use teh Spring-DM forum (http://forum.springframework.org/forumdisplay.php?f=43).

As for examples, besides Guillaume's code sample and the screencast, one can also consider the Spring-DM integration tests (the reason why the testing framework was created in the first place).

Cheers,
Costin Leau

On Wed, Jun 4, 2008 at 3:13 PM, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
Once again, I think Spring-DM test support can somewhat fills this gap.
From a junit test, it creates an OSGi runtime where you can specify
the bundle you want to deploy, then run the junit tests inside the
test bundle which is automatically created.
I would encourage anyone wanting to do OSGi integration tests to take
a look at that first and see if it can fit their use case.

On Wed, Jun 4, 2008 at 2:55 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote:
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



--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/




Reply via email to