You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Robert Burrell Donkin <ro...@gmail.com> on 2008/05/31 09:02:10 UTC
Library Enabling Test Framework...?
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.
1 does such a library exist already?
2 if not:
2a is this just a crazy idea?
2b could it be made to work?
- robert
Re: Library Enabling Test Framework...?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sat, May 31, 2008 at 10:40 AM, Karl Pauls <ka...@gmail.com> wrote:
<snip>
>> 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.
>>
>> 1 does such a library exist already?
>
> Not really. The might be some stuff around that is related but afaik
> nothing that exactly does what you want (at least not open source).
>
>> 2 if not:
>> 2a is this just a crazy idea?
>
> Not at all. We would need some kind of integration test framework
> ourselves and discussed it a couple of times but nothing really
> emerged as of now...
i'll markmail...
>> 2b could it be made to work?
>
> It should not be super complicated although it might need some work.
:-)
> Felix is easily embeddable:
>
> http://felix.apache.org/site/launching-and-embedding-apache-felix.html
>
> and launches reasonable quickly.
cool
> It really depends on what it is your
> thinking of testing exactly?
just throwing around ideas ATM
i suppose that the the ideal would probably be being able to
transparently running a suite against a contained library but this is
probably a little ambituous to start off with
> I'd be interested in helping out as I'm sure others are as well...
great
- robert
Re: Library Enabling Test Framework...?
Posted by Karl Pauls <ka...@gmail.com>.
> over in JAMES, we'd like to OSGi enable our upcoming library releases
> so that they can be used unforked in OSGi environments.
Great!
> 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.
Sounds like a good approach.
> 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.
>
> 1 does such a library exist already?
Not really. The might be some stuff around that is related but afaik
nothing that exactly does what you want (at least not open source).
> 2 if not:
> 2a is this just a crazy idea?
Not at all. We would need some kind of integration test framework
ourselves and discussed it a couple of times but nothing really
emerged as of now...
> 2b could it be made to work?
It should not be super complicated although it might need some work.
Felix is easily embeddable:
http://felix.apache.org/site/launching-and-embedding-apache-felix.html
and launches reasonable quickly. It really depends on what it is your
thinking of testing exactly?
I'd be interested in helping out as I'm sure others are as well...
regards,
Karl
> - robert
>
--
Karl Pauls
karlpauls@gmail.com
Re: Library Enabling Test Framework...?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sat, May 31, 2008 at 1:13 PM, Karl Pauls <ka...@gmail.com> wrote:
> On Sat, May 31, 2008 at 1:30 PM, Niklas Gustavsson <ni...@protocol7.com> wrote:
>> On Sat, May 31, 2008 at 9:02 AM, Robert Burrell Donkin
>> <ro...@gmail.com> wrote:
>>> 1 does such a library exist already?
>>
>> Spring-DM has an integration testing framework that sounds close to
>> what you're looking for:
>> http://static.springframework.org/osgi/docs/current/reference/html/testing.html#testing:integration
>
> Excellent, I wasn't aware of this. I will give it a try.
+1
> Thanks :-)
+1
- robert
Re: Library Enabling Test Framework...?
Posted by Karl Pauls <ka...@gmail.com>.
On Sat, May 31, 2008 at 1:30 PM, Niklas Gustavsson <ni...@protocol7.com> wrote:
> On Sat, May 31, 2008 at 9:02 AM, Robert Burrell Donkin
> <ro...@gmail.com> wrote:
>> 1 does such a library exist already?
>
> Spring-DM has an integration testing framework that sounds close to
> what you're looking for:
> http://static.springframework.org/osgi/docs/current/reference/html/testing.html#testing:integration
Excellent, I wasn't aware of this. I will give it a try. Thanks :-)
regards,
Karl
> /niklas
>
--
Karl Pauls
karlpauls@gmail.com
Re: Library Enabling Test Framework...?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Sat, May 31, 2008 at 9:02 AM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> 1 does such a library exist already?
Spring-DM has an integration testing framework that sounds close to
what you're looking for:
http://static.springframework.org/osgi/docs/current/reference/html/testing.html#testing:integration
/niklas
Re: Library Enabling Test Framework...?
Posted by Costin Leau <co...@gmail.com>.
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 <gn...@gmail.com> 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 <ak...@apache.org> 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 <ni...@hedhman.org> 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/
>>
>
>
>
Re: Library Enabling Test Framework...?
Posted by Guillaume Nodet <gn...@gmail.com>.
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
On Wed, Jun 4, 2008 at 3:13 PM, Guillaume Nodet <gn...@gmail.com> 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 <ak...@apache.org> 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 <ni...@hedhman.org> 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/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Library Enabling Test Framework...?
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <ak...@apache.org> 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 <ni...@hedhman.org> 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/
Re: Library Enabling Test Framework...?
Posted by Costin Leau <co...@gmail.com>.
Toni Menzel wrote:
> Hi Costin,
>
Hey Toni,
> Thanks a lot for the reply to the obstacles.
> I will continue on the spring-DM ML today.
> For now: Pax Drone is a spike with very clear goals (as pointed out in
> the README) that are very different from spring-DM's solution.
> For this ML, the springDM test-support implementation is the most
> advanced solution for the original purpose (Robert) today.
>
> Btw, I have looked around before, too - aren't there more than this one
> (maybe this two in the future) in-framework testing solutions for OSGi ?
> I mean what are the felix or equinox (sorry, wrong group ;-) guys doing?
The felix/equinox devs can reply here better then I can. Knopflerfish
provides a junit testing framework also I believe, that uses XML for
communication.
> I mean, more and more enterprise companies are jumping onto OSGi without
> having a state of the art testing solution ?
> - Speaking of more than just minimal unit testing because OSGi is highly
> dynamic which should be part of the tests.
>
> Sure, tools like BND make building a snap. But that's just the beginning.
>
> Costin, Are you coming to Berlin next week ?
Unfortunately not, OSGi Community Event takes place at the same time as
SpringOne (where I'll be speaking on Spring-DM)...
Cheers,
>
> see you at spring dm again,
> Toni
>
> On 04.06.2008, at 17:01, Costin Leau wrote:
>
>> Toni Menzel wrote:
>>> Yes, documentation is on the way.
>>> The project goals as well as the main obstacles for not using
>>> springDM's implementation can be found here:
>>> https://scm.ops4j.org/repos/ops4j/laboratory/users/tonit/incubator/drone/README
>>>
>> Hi Toni,
>>
>> I wasn't aware of the obstacles you mentioned in your link - have you
>> considered reporting or discussing this issues on Spring-DM mailing
>> list/forum? We're keen on improving the user experience.
>>
>> Since the topic was opened, I'd like to (briefly) address the issues
>> mentioned in the README:
>>
>> a) "it pulls in a lot of dependencies (about 8 extra bundles that are
>> just infrastructure)"
>> A: this is completely customizable. In fact all the jars are read
>> from a property file which can be modified (declaratively or
>> programatically). Only half of the bundles (or less) are needed - the
>> rest are provided as convenience for installing Spring-DM
>> infrastructure. If size is an issue, the util methods used can be
>> potentially implemented locally but frankly, the extra 50-100K doesn't
>> seem to be worth it. For 1.1.x we played with the idea of profiles but
>> we postponed this for 1.2 (see below). However, you can do this
>> yourself now by selecting what bundles you want installed based on
>> some criteria.
>>
>> b) "uses base-classloader to hold and transfer data from the osgi
>> framework"
>>
>> This is actually on purpose. Remoting involves serialization which is
>> quite slow. To improve performance we went from small serialization
>> (the initial design) to class loading which improved performance
>> around 20% on a simple code base. The numbers are not accurate since
>> we didn't do extensive benchmarking but it did show improvements in
>> the nightly builds. Everything takes place inside the same VM so the
>> test results or all the objects and their state are returned to the
>> IDE in pristine state, w/o any transformation. Remoting was not (nor
>> is) on the roadmap but we can consider it (there are many things that
>> can be said on OSGi and remoting).
>>
>> c) "hard to extend (singletons, classloader tricks,big classes,many
>> dependencies)"
>>
>> The testing framework was aimed initially for Spring-DM alone. It can
>> be customized quite a lot and extended (from OSGi platforms to how
>> bundles are retrieved or installed). Since we use Junit 3, we're
>> forced to have certain parents and are somewhat limited in what we can
>> do.
>> However, post 1.1, we plan to improve the testing framework by
>> integrating it with JUnit 4 and TestNG.
>>
>> As for the singletons, that's actually on purpose - you don't want to
>> start a new OSGI framework for each test inside your test case. The
>> same for the Spring application context. If you really want to, then
>> just write another test case.
>> Again, the consideration here is speed.
>>
>> I'd be curios to know what sort of issues you ran with regard to class
>> loading as it doesn't interfere with plugability nor extension. You
>> keep mentioning but I don't see why this is a problem.
>>
>> These being said, I don't want to hijack this thread so please, if you
>> want to follow up (I hope you do), please consider using the Spring-DM
>> forum/mailing list.
>>
>> Cheers,
>> Costin
>>
>>> There will be an official announcement on the ops4j mailinglist along
>>> with "real" documentation on the ops4j wiki somehwat next week. (hope
>>> every one is subscribed to it ;-) ?)
>>> till then,
>>> /Toni
>>> -------- Original-Nachricht --------
>>>> Datum: Wed, 4 Jun 2008 16:41:26 +0300
>>>> Von: "Alin Dreghiciu" <ad...@gmail.com>
>>>> An: dev@felix.apache.org
>>>> Betreff: Re: Library Enabling Test Framework...?
>>>> As Guillaume pointerd out, Spring DM Testing support should be able to
>>>> solve your use case.
>>>> Toni Menzel is also working on such a testing support as part of Pax
>>>> Drone, which is now in hie incubator but I expect that soon to be
>>>> "ready" to use. There is no documentation yet about, but soon. Toni?
>>>>
>>>> Alin Dreghiciu
>>>>
>>>> On Wed, Jun 4, 2008 at 3:55 PM, Alex Karasulu <ak...@apache.org>
>>>> 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 <ni...@hedhman.org>
>>>> 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
>>>>>>
>>>>
>>>>
>>>> --
>>>> Alin Dreghiciu
>>>> http://www.ops4j.org - New Energy for OSS Communities - Open
>>>> Participation Software.
>>>> http://www.qi4j.org - New Energy for Java - Domain Driven Development.
>>>> http://malaysia.jayway.net - New Energy for Projects - Great People
>>>> working on Great Projects at Great Places
>
>
--
Costin
Re: Library Enabling Test Framework...?
Posted by Toni Menzel <to...@gmx.de>.
Hi Costin,
Thanks a lot for the reply to the obstacles.
I will continue on the spring-DM ML today.
For now: Pax Drone is a spike with very clear goals (as pointed out in
the README) that are very different from spring-DM's solution.
For this ML, the springDM test-support implementation is the most
advanced solution for the original purpose (Robert) today.
Btw, I have looked around before, too - aren't there more than this
one (maybe this two in the future) in-framework testing solutions for
OSGi ?
I mean what are the felix or equinox (sorry, wrong group ;-) guys
doing? I mean, more and more enterprise companies are jumping onto
OSGi without having a state of the art testing solution ?
- Speaking of more than just minimal unit testing because OSGi is
highly dynamic which should be part of the tests.
Sure, tools like BND make building a snap. But that's just the
beginning.
Costin, Are you coming to Berlin next week ?
see you at spring dm again,
Toni
On 04.06.2008, at 17:01, Costin Leau wrote:
> Toni Menzel wrote:
>> Yes, documentation is on the way.
>> The project goals as well as the main obstacles for not using
>> springDM's implementation can be found here:
>> https://scm.ops4j.org/repos/ops4j/laboratory/users/tonit/incubator/drone/README
> Hi Toni,
>
> I wasn't aware of the obstacles you mentioned in your link - have
> you considered reporting or discussing this issues on Spring-DM
> mailing list/forum? We're keen on improving the user experience.
>
> Since the topic was opened, I'd like to (briefly) address the issues
> mentioned in the README:
>
> a) "it pulls in a lot of dependencies (about 8 extra bundles that
> are just infrastructure)"
> A: this is completely customizable. In fact all the jars are read
> from a property file which can be modified (declaratively or
> programatically). Only half of the bundles (or less) are needed -
> the rest are provided as convenience for installing Spring-DM
> infrastructure. If size is an issue, the util methods used can be
> potentially implemented locally but frankly, the extra 50-100K
> doesn't seem to be worth it. For 1.1.x we played with the idea of
> profiles but we postponed this for 1.2 (see below). However, you can
> do this yourself now by selecting what bundles you want installed
> based on some criteria.
>
> b) "uses base-classloader to hold and transfer data from the osgi
> framework"
>
> This is actually on purpose. Remoting involves serialization which
> is quite slow. To improve performance we went from small
> serialization (the initial design) to class loading which improved
> performance around 20% on a simple code base. The numbers are not
> accurate since we didn't do extensive benchmarking but it did show
> improvements in the nightly builds. Everything takes place inside
> the same VM so the test results or all the objects and their state
> are returned to the IDE in pristine state, w/o any transformation.
> Remoting was not (nor is) on the roadmap but we can consider it
> (there are many things that can be said on OSGi and remoting).
>
> c) "hard to extend (singletons, classloader tricks,big classes,many
> dependencies)"
>
> The testing framework was aimed initially for Spring-DM alone. It
> can be customized quite a lot and extended (from OSGi platforms to
> how bundles are retrieved or installed). Since we use Junit 3, we're
> forced to have certain parents and are somewhat limited in what we
> can do.
> However, post 1.1, we plan to improve the testing framework by
> integrating it with JUnit 4 and TestNG.
>
> As for the singletons, that's actually on purpose - you don't want
> to start a new OSGI framework for each test inside your test case.
> The same for the Spring application context. If you really want to,
> then just write another test case.
> Again, the consideration here is speed.
>
> I'd be curios to know what sort of issues you ran with regard to
> class loading as it doesn't interfere with plugability nor
> extension. You keep mentioning but I don't see why this is a problem.
>
> These being said, I don't want to hijack this thread so please, if
> you want to follow up (I hope you do), please consider using the
> Spring-DM forum/mailing list.
>
> Cheers,
> Costin
>
>> There will be an official announcement on the ops4j mailinglist
>> along with "real" documentation on the ops4j wiki somehwat next
>> week. (hope every one is subscribed to it ;-) ?)
>> till then,
>> /Toni
>> -------- Original-Nachricht --------
>>> Datum: Wed, 4 Jun 2008 16:41:26 +0300
>>> Von: "Alin Dreghiciu" <ad...@gmail.com>
>>> An: dev@felix.apache.org
>>> Betreff: Re: Library Enabling Test Framework...?
>>> As Guillaume pointerd out, Spring DM Testing support should be
>>> able to
>>> solve your use case.
>>> Toni Menzel is also working on such a testing support as part of Pax
>>> Drone, which is now in hie incubator but I expect that soon to be
>>> "ready" to use. There is no documentation yet about, but soon. Toni?
>>>
>>> Alin Dreghiciu
>>>
>>> On Wed, Jun 4, 2008 at 3:55 PM, Alex Karasulu <ak...@apache.org>
>>> 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 <ni...@hedhman.org>
>>> 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
>>>>>
>>>
>>>
>>> --
>>> Alin Dreghiciu
>>> http://www.ops4j.org - New Energy for OSS Communities - Open
>>> Participation Software.
>>> http://www.qi4j.org - New Energy for Java - Domain Driven
>>> Development.
>>> http://malaysia.jayway.net - New Energy for Projects - Great People
>>> working on Great Projects at Great Places
Re: Library Enabling Test Framework...?
Posted by Costin Leau <co...@gmail.com>.
Toni Menzel wrote:
> Yes, documentation is on the way.
> The project goals as well as the main obstacles for not using springDM's implementation can be found here:
> https://scm.ops4j.org/repos/ops4j/laboratory/users/tonit/incubator/drone/README
>
Hi Toni,
I wasn't aware of the obstacles you mentioned in your link - have you
considered reporting or discussing this issues on Spring-DM mailing
list/forum? We're keen on improving the user experience.
Since the topic was opened, I'd like to (briefly) address the issues
mentioned in the README:
a) "it pulls in a lot of dependencies (about 8 extra bundles that are
just infrastructure)"
A: this is completely customizable. In fact all the jars are read from
a property file which can be modified (declaratively or
programatically). Only half of the bundles (or less) are needed - the
rest are provided as convenience for installing Spring-DM
infrastructure. If size is an issue, the util methods used can be
potentially implemented locally but frankly, the extra 50-100K doesn't
seem to be worth it. For 1.1.x we played with the idea of profiles but
we postponed this for 1.2 (see below). However, you can do this yourself
now by selecting what bundles you want installed based on some criteria.
b) "uses base-classloader to hold and transfer data from the osgi framework"
This is actually on purpose. Remoting involves serialization which is
quite slow. To improve performance we went from small serialization (the
initial design) to class loading which improved performance around 20%
on a simple code base. The numbers are not accurate since we didn't do
extensive benchmarking but it did show improvements in the nightly
builds. Everything takes place inside the same VM so the test results or
all the objects and their state are returned to the IDE in pristine
state, w/o any transformation. Remoting was not (nor is) on the roadmap
but we can consider it (there are many things that can be said on OSGi
and remoting).
c) "hard to extend (singletons, classloader tricks,big classes,many
dependencies)"
The testing framework was aimed initially for Spring-DM alone. It can be
customized quite a lot and extended (from OSGi platforms to how bundles
are retrieved or installed). Since we use Junit 3, we're forced to have
certain parents and are somewhat limited in what we can do.
However, post 1.1, we plan to improve the testing framework by
integrating it with JUnit 4 and TestNG.
As for the singletons, that's actually on purpose - you don't want to
start a new OSGI framework for each test inside your test case. The same
for the Spring application context. If you really want to, then just
write another test case.
Again, the consideration here is speed.
I'd be curios to know what sort of issues you ran with regard to class
loading as it doesn't interfere with plugability nor extension. You keep
mentioning but I don't see why this is a problem.
These being said, I don't want to hijack this thread so please, if you
want to follow up (I hope you do), please consider using the Spring-DM
forum/mailing list.
Cheers,
Costin
> There will be an official announcement on the ops4j mailinglist along with "real" documentation on the ops4j wiki somehwat next week. (hope every one is subscribed to it ;-) ?)
>
> till then,
> /Toni
>
> -------- Original-Nachricht --------
>> Datum: Wed, 4 Jun 2008 16:41:26 +0300
>> Von: "Alin Dreghiciu" <ad...@gmail.com>
>> An: dev@felix.apache.org
>> Betreff: Re: Library Enabling Test Framework...?
>
>> As Guillaume pointerd out, Spring DM Testing support should be able to
>> solve your use case.
>> Toni Menzel is also working on such a testing support as part of Pax
>> Drone, which is now in hie incubator but I expect that soon to be
>> "ready" to use. There is no documentation yet about, but soon. Toni?
>>
>> Alin Dreghiciu
>>
>> On Wed, Jun 4, 2008 at 3:55 PM, Alex Karasulu <ak...@apache.org>
>> 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 <ni...@hedhman.org>
>> 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
>>>>
>>
>>
>> --
>> Alin Dreghiciu
>> http://www.ops4j.org - New Energy for OSS Communities - Open
>> Participation Software.
>> http://www.qi4j.org - New Energy for Java - Domain Driven Development.
>> http://malaysia.jayway.net - New Energy for Projects - Great People
>> working on Great Projects at Great Places
>
Re: Library Enabling Test Framework...?
Posted by Toni Menzel <to...@gmx.de>.
Yes, documentation is on the way.
The project goals as well as the main obstacles for not using springDM's implementation can be found here:
https://scm.ops4j.org/repos/ops4j/laboratory/users/tonit/incubator/drone/README
There will be an official announcement on the ops4j mailinglist along with "real" documentation on the ops4j wiki somehwat next week. (hope every one is subscribed to it ;-) ?)
till then,
/Toni
-------- Original-Nachricht --------
> Datum: Wed, 4 Jun 2008 16:41:26 +0300
> Von: "Alin Dreghiciu" <ad...@gmail.com>
> An: dev@felix.apache.org
> Betreff: Re: Library Enabling Test Framework...?
> As Guillaume pointerd out, Spring DM Testing support should be able to
> solve your use case.
> Toni Menzel is also working on such a testing support as part of Pax
> Drone, which is now in hie incubator but I expect that soon to be
> "ready" to use. There is no documentation yet about, but soon. Toni?
>
> Alin Dreghiciu
>
> On Wed, Jun 4, 2008 at 3:55 PM, Alex Karasulu <ak...@apache.org>
> 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 <ni...@hedhman.org>
> 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
> >>
> >
>
>
>
> --
> Alin Dreghiciu
> http://www.ops4j.org - New Energy for OSS Communities - Open
> Participation Software.
> http://www.qi4j.org - New Energy for Java - Domain Driven Development.
> http://malaysia.jayway.net - New Energy for Projects - Great People
> working on Great Projects at Great Places
Re: Library Enabling Test Framework...?
Posted by Alin Dreghiciu <ad...@gmail.com>.
As Guillaume pointerd out, Spring DM Testing support should be able to
solve your use case.
Toni Menzel is also working on such a testing support as part of Pax
Drone, which is now in hie incubator but I expect that soon to be
"ready" to use. There is no documentation yet about, but soon. Toni?
Alin Dreghiciu
On Wed, Jun 4, 2008 at 3:55 PM, Alex Karasulu <ak...@apache.org> 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 <ni...@hedhman.org> 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
>>
>
--
Alin Dreghiciu
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
http://malaysia.jayway.net - New Energy for Projects - Great People
working on Great Projects at Great Places
Re: Library Enabling Test Framework...?
Posted by Alin Dreghiciu <ad...@gmail.com>.
As Guillaume pointerd out, Spring DM Testing support should be able to
solve your use case.
Toni Menzel is also working on such a testing support as part of Pax
Drone, which is now in hie incubator but I expect that soon to be
"ready" to use. There is no documentation yet about, but soon. Toni?
Alin Dreghiciu
On Wed, Jun 4, 2008 at 3:55 PM, Alex Karasulu <ak...@apache.org> 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 <ni...@hedhman.org> 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
>>
>
--
Alin Dreghiciu
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
http://malaysia.jayway.net - New Energy for Projects - Great People
working on Great Projects at Great Places
Re: Library Enabling Test Framework...?
Posted by Alex Karasulu <ak...@apache.org>.
On Wed, Jun 4, 2008 at 11:46 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Wednesday 04 June 2008 20:55, Alex Karasulu wrote:
> > 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.
>
> Yes, I know Robert asked for integration testing, BUT if you are totally
> new
> to OSGi, you need to get the build right first. AND if you are "only" going
> for getting your Manifest in order, and not a fully fledged OSGi app, then
> that will be a lot already.
> And not actively monitoring this list, it might not be apparent that BND
> will
> give you a lot of the things you need to get that part right.
>
Yep yep all good very points indeed for someone just diving in. BND is the
starting point you're right. I thought there might have been some
misinterpretation and it sounded to me like Robert wanted something I too
desire. It was a good opportunity for me to ask again :).
Seems there are more options than I had initially thought on this front
thanks to people like Mr. Nodet and others pointing out the Spring-DM goods.
Please do carry on ... would love to see how James goes forward.
Regards,
Alex
Re: Library Enabling Test Framework...?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 04 June 2008 20:55, Alex Karasulu wrote:
> 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.
Yes, I know Robert asked for integration testing, BUT if you are totally new
to OSGi, you need to get the build right first. AND if you are "only" going
for getting your Manifest in order, and not a fully fledged OSGi app, then
that will be a lot already.
And not actively monitoring this list, it might not be apparent that BND will
give you a lot of the things you need to get that part right.
Now, Robert, it might be helpful to know if JAMES is going to be an OSGi
application (i.e. deployable as an operational server in OSGi without further
work) or "just" have its manifest in proper order for others to embed it in
their OSGi applications.
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
Re: Library Enabling Test Framework...?
Posted by Alex Karasulu <ak...@apache.org>.
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 <ni...@hedhman.org> 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
>
Re: Library Enabling Test Framework...?
Posted by Niclas Hedhman <ni...@hedhman.org>.
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