Beyond the obvious goal of implementing the OSGi spec the other part to having the
OSGi framework implemented on top of the MC/Deployers is so you can control
other types of deployments using the Bundle/Service api.

This is a standardised api. Which means some people are much more confortable
writing to it than for example the JBoss MainDeployer api.

There's also the reverse requirement that the OSGi components
should work properly from the MC/Deployers.

Some typical use cases:

1 ) INSTALLATION

I want to deploy a webapp. I do:

Bundle myWar = someBundle.installBundle(myWarURL);

Since this is not an OSGi bundle it will automatically move to the ACTIVE state
(unlike normal bundles which which require a bundle.start() unless there
is some other rule to do it, e.g. start level service or persistent state, etc).

This worked until the latest changes.

1a) It should be possible to deploy OSGi bundles using the MainDeployer, e.g.
via hot deployment.

AFAIK this works?

2) CONTROLLING LIFECYCLE

I can use the OSGi api to control the lifecycle of non-osgi deployments.
e.g.

Bundle tomcat = ...;
tomcat.stop();
// do stuff
tomcat.start();

This also worked until the latest changes.

2a) In reverse you should be able to control the OSGi bundles and services
using the MC/Deployers api.

This works for deployments, but it isn't going to understand things like the
AUTO_START_PROPERTY which is unknown to the MC code.

3) ACCESSING SERVICES

I should be able to use the OSGi api to access jboss services, e.g.

ServiceReference[] dataSources = bundleContext.getServiceReferences(javax.sql.DataSource.class.getName(), null);

Those services should look like they are associated with a Bundle (the BundleState
associated with the DeploymentUnit that created the datasource) and do all
the notifications, security checks etc. that OSGi requires.

This doesn't work. See the "ServiceTracking" thread where Ales and I discussed
how to implement this.

3a) In reverse, OSGi deployed services should be available to the MC
for use in dependency injection.

4) INTEGRATED CLASSLOADING

I should be able to import classes from JBoss deployments.

e.g.

ImportPackage: javax.ejb;version=3.0

This doesn't work for the reasons described on the "resolver is wrong" thread.

4a) In reverse OSGi bundle classes should be available
to non-osgi deployments.

This works, but the rules will likely be inconsistent to what the
ResolverPlugin is doing, leading to classloading problems?

5) MANAGEMENT

Other deployments and services that are not OSGI deployments should still
appear in things like the package admin.

5a) In reverse, OSGi bundles and services should be available to JBoss
management tools, e.g. the management console

6) OTHER OSGI FEATURES

Other OSGi features, like lazy start should work for other non-osgi deployments.
Or you should be able to add a war to an osgi start level.
etc.

6a) You can use JBoss specific features to augment/change the standard behaviour of an
osgi-bundle. e.g. adding a META-INF/jboss-classloading.xml to change the
classloading requirements without touching the manifest. (This would be essentially
what the management console will do if you modify the classloading rules there).