6:48 a.m.
Reposted from OPS4J lits:
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 Bridge 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(a)jboss.com <
do-not-reply(a)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? I 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#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...
_______________________________________________
jboss-osgi-users mailing list
jboss-osgi-users(a)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.