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" <[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
