Define non OSGi bundle handling by the Framework

[thomas.diesler]

https://jira.jboss.org/jira/browse/JBOSGI-203

There have been changes going forth and back with respect to non-osgi deployment handling. The objectives and scope of functionality still need to be defined.

I had to roll-back recent changes in the handling of non-osgi deployemnts because those broke AS integration

You can run the AS integration test using

http://jbmuc.dyndns.org:8280/hudson/job/jbossosgi-jdk16/

The minimum requirement to verify the validity of AS integration related changes would be to startup AS and check that you can see the jboss-osgi console.

http://jbmuc.dyndns.org/jboss-osgi/userguide/html/ChapGettingStarted.html#SecWebConsole

Could you please present your ideas with respect to non-osgi bundle handling by the framework?

cheer

[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

[adrian.brock]

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. ;-)

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

[alesj]

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

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

[adrian.brock]

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).