Regarding Pax Exam and Husky these two frameworks are almost the same. And both are working with an remote framework. Remote meaning that the Client Runner and Osgi Framework are running in separate processes. Now, of course that we do not share the same names like Conecor, invoker, bridge but architecture wise is the same. With one diff: we consider that all the tests have to run the osgi container and so we do not have the 泎ridge part in every test method. In rest, all the things like extender based on manifest headers, injection of bundle context, ...

I would even say that Pax Exam adds more to the table because you can configure the osgi framework use for tests for things like system properties, boot delegation packages, system packages, provisioned bundles, ... IT may be that Husky supports that too but was not obvious from the blog post.

After all, I do not really care if there are other test frameworks over there beside the split effort. As it looks like we think alike why don't you join us? Pax Exam provides an extension point where you can plug in another test container , beside pax runner based one. Implement that based on JBoss and just have it in the classpath and your pax exam tests will be running in JBoss.

Actually the collaboration could be batter as we can work on adding support for JBoss in Pax Runner. This will mean that jboss can be easy started and used by pax runner users, directly used in Pax Exam without the need to implement the container explained above, could be used n Eclipse via Pax Runner plugin, ... WDYT?

On Thu, Oct 15, 2009 at 12:01 PM, thomas.diesler@jboss.com <do-not-reply@jboss.com> wrote:

Kevin sais:

anonymous wrote :
捤 Congrats on the release, I am looking forward to playing with it.
捤
捤 Can you explain the benefits of our own integration over something like the pax-runner/pax-exam framework? 狢 have been using those for OSGi work and am very happy with it, what functionality do you provide above and beyond theirs?
捤
捤 Do you plan on supporting Knoplerfish?
捤

pax-runner/pax-exam is probably not much different to jboss osgi runtime/husky as long as you use the felix or equinox, in an embedded scenario.

The main objective of JBoss OSGi however is to bring OSGi functionality to the JBoss Application server. That JBoss OSGi has its own standalone runtime and can be bootstrapped embedded in you application is a by-product if you like.

With Beta4 you also get the first Alpha release of our own OSGi Framework implementation that is based on the JBoss Microcontainer.

Q: Why would we want to write our own OSGi Framework, if there are good open source alternatives out there?

A: Because eventually we want to bring added value to our customers that they can leverage the OSGi technology and at the same time talk to existing services that are deployed on JBoss. We would like to access OSGi services from EJB3, MCBeans, MBeans, WebBeans, and vica versa. This type of cross-component model integration would not be possible if we deployed a 3rd party framework like Felix or Equinox into JBoss.

For details on the various runtime model see: http://jbossosgi.blogspot.com/2009/06/jboss-osgi-runtime-as-integration.html

Because JBoss integration is at the heart of everything I do, I needed to find a way to write a plain JUnit4 test case and run that against multiple OSGi Frameworks in embedded mode as well as integrated in JBoss.

So what I actually do in Hudson is:

#1 build the installer
#2 auto execute the installer with a choice of container/framework
#3 run the test suite against that installation using a given jdk

I that way I can be sure that every functionality I ship and advertise actually runs in JBoss. Pax-Exam does not support the notion of remote OSGi Framework AFAIK.

If you'd like to read more on Husky, have a look at

http://jbossosgi.blogspot.com/2009/10/osgi-unit-testing.html

Here is the set of requirements that I had

# The solution MUST support plain JUnit4 POJO test cases
# There SHOULD be no requirement to extend a specific test base class
# There MUST be no requirement on a specific test runner
# There SHOULD be a minimum test framework leakage into the test case
# The test framework MUST support embedded and remote OSGi Runtimes with no change required to the test
# The same test case MUST be executable from outside as well as from within the OSGi Framework
# There SHOULD be a pluggable communication layer from the test runner to the OSGi Framework
# The test framework MUST NOT depend on OSGi Framework specific features
# There MUST be no automated creation of test bundles required by the test framework

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260471#4260471

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260471
_______________________________________________
jboss-osgi-users mailing list
jboss-osgi-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-osgi-users

--
Alin Dreghiciu
Software Developer
My profile: http://www.linkedin.com/in/alindreghiciu
My blog: http://adreghiciu.blogspot.com
http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.