Re: [jboss-as7-dev] bundles as modules?

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