This is a requirements document for AS modularization.

Please do not remove any bullet points.  If a requirement is to be removed, please strike it out so that the numbering remains consistent.

1. Most or all All of the libraries distributed with JBAS should be repackaged as modules.  (Reference: https://jira.jboss.org/jira/browse/JBAS-1796)
   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.
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. Modules will have an artifact ID, a group ID, and a version number, like Maven artifacts.  The combination of artifact ID, group ID and version number is globally unique.
3. Module bundles should not need 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 & group ID, artifact ID, and version (Note: I think we can do this today in jboss-cl).
5. Deployers which support deployment units that conform to specifications such as EJB will have to implicitly include module dependencies for any APIs which they support (like javaee for example).
   1. Thus such deployment units will themselves have to be implicitly or explicitly modularized, at least to some extent, in order to correctly isolate them from each other as well as correctly express dependencies.
6. Since the vast bulk of third-party libraries are not going to modularize according to our standard, we need to wrap and redistribute any such libraries as modules.
   1. In Maven, we should keep a separate groupId for modules versus raw artifacts where we keep the repackaged modules.
   2. This means that there's an extra layer of indirection between project releases and AS inclusion, for better or worse, since the AS depends on the module, which is built from the project release.
7. Module loading should support multiple strategies.
   1. A filesystem-backed strategy using a directory layout akin to Maven should be supported, where the group ID and version of a module is used to locate the artifact directory.  The runtime module metadata should exist separately from the artifact itself; this will simplify module packaging.
   2. A network-backed strategy might also be useful - allowing modules to be downloaded and installed on demand at runtime.