This content has been marked as final.
Show 6 replies
-
1. Re: Define non OSGi bundle handling by the Framework
thomas.diesler Nov 11, 2009 7:49 PM (in response to thomas.diesler)To learn howto setup the hudson QA environment locally, have a look at
http://jbmuc.dyndns.org/jboss-osgi/userguide/html/ChapGettingStarted.html#SecHudson -
2. Re: Define non OSGi bundle handling by the Framework
adrian.brock Nov 18, 2009 10:12 AM (in response to thomas.diesler)"thomas.diesler@jboss.com" wrote:
To learn howto setup the hudson QA environment locally, have a look at
http://jbmuc.dyndns.org/jboss-osgi/userguide/html/ChapGettingStarted.html#SecHudson
How do I run this as a plain testsuite?
Why aren't there regression tests for these features in reactor/framework?
Each feature should have a unit test. Integration testing is a secondary test.
If I can run the reactor/framework tests and it is 100% then all the supported features
are working. Something without a unit test is NOT a supported feature.
Adrian Brock's 1st Law of Programming.
It it ain't tested it doesn't work.
1st Law Corollary
It it ain't tested the feature doesn't exist. ;-) -
3. Re: Define non OSGi bundle handling by the Framework
thomas.diesler Nov 20, 2009 5:34 AM (in response to thomas.diesler)
Adrian Brock's 1st Law of Programming.
It it ain't tested it doesn't work.
1st Law Corollary
It it ain't tested the feature doesn't exist. ;-)
Sure, these are the laws I also work according to.
Why aren't there regression tests for these features in reactor/framework?
JBoss OSGi supports multiple OSGi frameworks, for the reason that standard OSGi is already usable in AS.
What we do with the OSGi example and functional test is a specific solution to the general problem of Maven integration testing
http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing
Anyhow, the MC framework needs to work in AS and the OSGi examples must run in AS. This is not something you can do in an Eclipse unit test.
I realize, that building the installer, installing the framework, starting the target container, running the examples against the target container is not a practical prerequisite for an SVN commit.
However, everybody should at least be aware of the functionality that already works and is being tested. One click on the public hudson instance can pickup potential integration issues, which can then be looked at and fixed locally.
It'd be good if you could trigger the integration tests as part of your normal commit routine. -
4. Re: Define non OSGi bundle handling by the Framework
alesj Nov 20, 2009 6:05 AM (in response to thomas.diesler)"thomas.diesler@jboss.com" wrote:
Anyhow, the MC framework needs to work in AS and the OSGi examples must run in AS. This is not something you can do in an Eclipse unit test.
It'd be good if you could trigger the integration tests as part of your normal commit routine.
Although I understand and support this,
this is not always possible - see my latest commits.
For me in order to move fwd, I need to work on Kernel 2.2.x,
which is not yet in AS, and will only be available for AS6.
The same will probably go for Adrian's work on CL's LifeCycle / Resolver.
I guess this requires some automation on whether it even makes sense to run tests on AS.
e.g. libs compatibility
Since in this case you cannot solve the problem with a simple lib change,
as the changes affect the stuff beyond encapsulated MC projects.
e.g. ControllerContext::ungetTarget --> AS' JMX + MC int -
5. Re: Define non OSGi bundle handling by the Framework
thomas.diesler Nov 20, 2009 6:31 AM (in response to thomas.diesler)Yes, all this exposes is when we have a certain functionality available in JBoss OSGi. An uncoordinated update of core components would simply result in the MC Framework not being usable in AS. This is something we don't want either ;-)
If we need to update a core library in AS (i.e. one that we cannot simply replace), then there should be an AS issue created for that which is a dependency on the some JBoss OSGi release issue. -
6. Re: Define non OSGi bundle handling by the Framework
adrian.brock Nov 23, 2009 4:12 AM (in response to thomas.diesler)"thomas.diesler@jboss.com" wrote:
What we do with the OSGi example and functional test is a specific solution to the general problem of Maven integration testing
http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing
Anyhow, the MC framework needs to work in AS and the OSGi examples must run in AS. This is not something you can do in an Eclipse unit test.
I realize, that building the installer, installing the framework, starting the target container, running the examples against the target container is not a practical prerequisite for an SVN commit.
However, everybody should at least be aware of the functionality that already works and is being tested. One click on the public hudson instance can pickup potential integration issues, which can then be looked at and fixed locally.
That's not what I'm saying. I mean why isn't this feature being properly unit tested in
framework/reactor?
The FrameworkTest lets you setup a "minimal" JBoss instance (without all
the other JavaEE services - just the basic OSGi stuff).
So it should be possible to write a unit test for something that is broken in the integration
tests so it won't regress in future by a bad commit in framework/reactor.
On the thirdparty library stuff. The integration tests should not be running off
reactor/framework trunk. The version used there should only be updated
when the AS and osgi framework agree about thirdparty dependencies.
i.e. once the thirdparty stuff has been updated into the AS at the end of the
latest changes (once they are stable).