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" <[EMAIL PROTECTED]>
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 <[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
--
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
