I will include a section on project structure in the development process guide. I will post a pointer to that section here once we publish later today.
To what degree are we going to decompose the source tree? Take the example in the link previously given:
Without additional refactoring to reduce dependencies, extracting the Remoting module would require the extraction of 9 other existing modules. The Remoting module may currently be overly-coupled, but surely there is some coupling there that is legitimate. So we will need to be able to deal with some level of decomposition whether or not we extract every module.
If a component is only going to be released as a part of the application server, it makes sense to keep it in that source tree. But if it is going to be released as part of more than one project, it will need to be extracted.
So, to make this concrete, the criteria for extraction is:
1. Is it useful outside of the AS as standalone project?
2. Will it be released as a part of more than one container project?
3. Is it a dependency of a project which falls under #1 or #2?
#2 is predicated on the assumption that we will have multiple integation projects. We currently have one container project -- the AS. If we have, say, a seperate POJO Server project, it seems like we would want many services to be included in both projects.
Sorry that this may not be the right moment to jump in. :-) But I don't see the project structure contains aop and cache, for example. Should I assume that in the future checking out jboss-head, for example, won't check out those *standalone* modules either?
The example in the diagram illustrates that components will be extacted from the source tree. Certainly, aop & cache make sense as standalone components. The question is, how far do we want to take this? Do we want to extract all components into their own projects?
I think we can extract pretty much any root directory under the jboss tree (and probably should). This would start with common (as you noted in your diagram) and go from there (since common should not have any other module that it depends on). Hopefully we won't have any circular dependancies (which would cause a build problem now anyways).