Of the top ten goals listed for AS6 (as listed here: http://www.jboss.org/community/wiki/JBossASTop10 ), at five will be directly served by modularizing the AS. I think everyone is in full agreement that it's something we can do, and something we should do. I want to expand on some of the details of what it would entail. It's apparent that the Java universe is moving towards a module-based architecture. The question is, how do we want to distribute our modules? We have two different module architectures available today. Thomas is running full steam ahead on figuring out how to distribute our stuff as OSGi bundles, and (as far as I understand anyway) the MC module system is intended to be a functional superset of OSGi, which would enable us to eventually integrate OSGi support directly into the MC. Neither route is fully developed yet though, so I'd like to put forth a few basic requirements for whatever module system we use. They're listed here: http://www.jboss.org/community/wiki/JBossAS6ModularizationRequirements but I'll copy them inline. Please comment on this thread or on the article. Don't be afraid to comment even if you think it's redundant/stupid/whatever; and of course don't hesitate to point out any misunderstanding/stupidity on my part. Here's the first quick draft: 1. Most or all of the libraries distributed with JBAS should be repackaged as modules. 1. This means that we'd need a way, on bootstrap, to "retroactively" modularize anything on the boot classpath that has to be available as a module at runtime. (Note: Any ideas?) 2. Modules will have strictly defined dependencies. 1. This means that deployments will only "see" APIs that they depend on, and only the versions that they depend on. 2. This also means that more than one version of a module can be present at the same time (theoretically anyway). 3. Module bundles should *not* have to be initially scanned on startup. This will be critical to keep startup time sane. 1. We should be able to put 5000 modules in a common lib directory, and not one of those files will be touched until some deployment depends on one of them; then, only that module should be loaded, followed by any of its dependencies. 2. This implies the need for some kind of ModuleLoader mechanism, which is similar to a ClassLoader in that it will scan the filesystem to load a module only when a specific module+version is requested, and it also implies a connection between the bundle naming convention and the module name (so that the loader won't have to scan a whole directory trying to find a specific module). 4. For any given Class, it should be possible to identify its module name & version (Note: I think we can do this today in jboss-cl). - DML