What do you mean? Bundle become modules when they get deployed at runtime. The reason that the 'bundles' directory exists is that the artefacts in there have their respective dependencies defined in standard OSGi metadata, which makes them bundles (i.e. a bundle cannot have a modules.xml file). Perhaps you could explain (again) the motivating goal for your question. cheers --thomas On Apr 12, 2013, at 4:46 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler JBoss OSGi Lead JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

On Apr 16, 2013, at 2:56 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: This may relate to the Provisioner service 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. Don't what this means either ;-) but I regularly talk with him so I can probably find out cheers --thomas xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler JBoss OSGi Lead JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

On Apr 16, 2013, at 3:18 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: 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) There should be no performance hit for that process. The Resolver could have a persistent view of wiring metadata that can be computed at build time. Performance wise this would be equivalent to reading module.xml files only that there is a guarantee that the wiring is consistent and that dependencies can be defined in a modular fashion. 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. xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler JBoss OSGi Lead JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx