felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toni Menzel <tonimen...@gmx.de>
Subject Re: Library Enabling Test Framework...?
Date Thu, 05 Jun 2008 07:45:47 GMT
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  

Costin, Are you coming to Berlin next week ?

see you at spring dm again,

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" <adreghiciu@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 <akarasulu@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 <niclas@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

View raw message