On Apr 16, 2013, at 3:18 PM, Bill Burke <bburke@redhat.com> wrote:

On 4/16/2013 9:07 AM, Thomas Diesler wrote:

On Apr 16, 2013, at 2:56 PM, Bill Burke <bburke@redhat.com
<mailto:bburke@redhat.com>> wrote:

I'm trying to make a AS distribution that has no jars. Instead,
metadata points to a maven repository location for those jars. I've
patched Jboss Modules to make this work, but have no solution for OSGi.

This may relate to the Provisioner service
<http://community.jboss.org/wiki/ProvisionerServiceAndFeatureDeployment> topic.
We already have a component that understands Maven coordinates and can
provide named resources. If you are thinking of a special ModuleLoader
that can fetch modules on demand then this loader should preferably
simply call the Repository IMHO. In the near future it could call the
Provisioner service with the top level Requirements.

Here's my pull request.

https://github.com/jbossas/jboss-modules/pull/28

With this patch, only jar you need to boot jboss is jboss-modules.jar. It will optionally download (or look in local maven repository) for any other required jars. I've written a bunch of long emails why this feature is interesting, I could forward them if you're interested.

I don't see why we'd want an AS dependency on some OSGi service. The idea of only needing one *local* jar to boot AS is much more appealing, IMO.

I'd say that "one local jar" should first fetch a component that can provision the system in a consistent way. It would then work with a small set of top level requirements (i.e. one per subsystem). The transitive closure of jars that actually need to be provisioned to satisfy the feature requests should to be computed by a authority that guarantees a consistent solution (i.e. a Resolver) - the maven dependency tree is not suitable for this IMHO.

Yes, there should be no dependency on the OSGi Framework. The org.osgi.resource API qualifies to model resources with associated capabilities/requirements just like any other API. It has intentionally been designed such that it is independent of OSGi. A resource can of course define named requirements on other resources as we do with modules.xml today. A named dependency however is a form of tight coupling, which violates the fundamental principal of modularity that you should be able to reason about A without having to know that B has a dependency on A - A and B should only define their own respective caps/reqs. It is the job of a resolver to figure out that B actually depends on A and not on some other resource that also provides a capability that B requires (e.g. a java package)

David Lloyd said he didn't understand why your bundles weren't
deployed as modules. I don't know what that means either, but that's
what he said.

Don't what this means either ;-) but I regularly talk with him so I can
probably find out

Maybe that the OSGi layer delegates to JBoss Modules to resolve classloader dependencies? That would make sense…

Dependencies defined by OSGi metadata are complex and go beyond the hard wired named dependencies that we have today - so in fact it would not make sense at all if you want to support the de-facto standard for modularity. Another standard that defines dependencies between resources is feasible and in its most simplistic form would use named dependencies. JBoss could decide to ignore the standard and treat everything in a proprietary way (i.e. with metadata defined in modules.xml). The result would be that JBoss says: I know the dependencies of Foo better than the author of Foo and replace loosely coupled dependency definitions by hard wired named dependencies. This would still work as long as Foo is part of the build process and subject to extensive QA validation. It would break, when Foo is allowed to come in late (i.e. at runtime). JBoss would require the author of Foo to provide an alternative set of named dependencies in a propriatary way that is only valid for a specific state of the runtime environment (i.e. the author/deployer must know the set of named resources that are available at deploy time). As a result Foo is not a module any more that can be reasoned about independently.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com