Merci. I suspect that this would not be very useful (yet). Every jar that exists in AS 5.x which is not an OSGi bundle is loaded by the OSGi System Class Loader. To access classes from these jars you must explicitly include the package name in the configuration, which is currently defined as: <entry> <key>org.osgi.framework.system.packages</key> <value> javax.management, javax.xml.parsers, org.jboss.logging, org.jboss.osgi.service, org.jboss.osgi.spi.management, org.osgi.framework; version=1.4, org.osgi.service.packageadmin; version=1.2, org.osgi.service.startlevel; version=1.1, org.xml.sax </value> </entry> Instead I'd propose to compile a list of jars that are the primary candidates to become OSGi bundles. This essentially means adding the OSGi Manifest Headers to MANIFEST.MF Once we have that other projects can define their binary dependencies in terms of OSGi Imports. Also please note, that the current JBossOSGi release does not (yet) use the MC as the underlying OSGi framework, which I believe is a prerequisite to OSGi enable other jboss services large scale. Having said that, the current JBossOSGi release will already allow us to turn core services into bundles (i.e. remoting, cache, logging, etc) and document and test them. Having the OSGi Manifest Headers in those jars does not hurt AS 5.x. Generally, the packages defined by 'org.osgi.framework.system.packages' should be at a bare minimum. cheers -thomas Dimitris Andreadis wrote: -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx