module == smallest level compilable unit, a maven project
subproject == a set of modules that can be built at once with a set of dependencies none of which require any module from the subproject
project == a set of subprojects that can be built in some order.
The uber-build works by piling all of geronimo, tranql, tranql-connector, and openejb into one subproject, and that obviously works. If I understand correctly, you are wondering why we should divide the pile into more than one subproject.
Let's consider just openejb. One of the goals of geronimo is to provide a framework or platform for integrating other j2ee containers such as tomcat, jetty, and indeed openejb. If we had a situation where some core component of geronimo depended on an openejb class or module, we would have demonstrated that openejb is not pluggable: it is really a core part of geronimo. By moving openejb compilation into a separate subproject, we demonstrate with every build that geronimo core is not dependent on openejb.
Another goal has been to separate all the deployment stuff into separate "builder" modules: one of the purposes is to enable running a geronimo server with no deployment abilities, only the ability to run precompiled configurations. We can (and IMO should) verify some things about this separation by compiling the non-builder and builder modules in separate subprojects. (I have not mentioned this previously in this thread).
So, the purpose of having subprojects is to enforce more structure on the project than given purely by modules.
Many thanks, david jencks
On Apr 29, 2005, at 8:03 AM, anita kulshreshtha wrote:
AIUI, I do not have to worry about the cyclic dependencies in our automated build/release because Maven detects cyclic dependency early on and aborts the build. In all other cases it will come up with an acceptable order to build such that the artifacts have been built before they are needed. I do not see why we need this grouping of modules. May be I am missing something? As far as maven (multiproject) is concerned modules and subprojects are same.
Thanks Anita --- David Jencks <[EMAIL PROTECTED]> wrote:
On Apr 28, 2005, at 6:32 AM, anita kulshreshtha wrote:
--- David Jencks <[EMAIL PROTECTED]> wrote:I'd like to attempt to clarify one of my main points.
<snip>Maven 2 uses 'scope' to limit the transitivityofthe dependency. What is the nature of dependencyofopenejb on geronimo compiletime/runtime/testtime?Whatabout tranql?
Currently, and for a long time, the "uber-build" works, where all subprojects/modules from geronimo, tranql, tranql-connector, and openejb are put in a big pile and maven figures out an order to build them in. This demonstrates that there are no circular dependencies on the subproject/module level. But, in my view, if we accept this level of structure, we should combine all this into one project and abandon separate tranql and openejb. I don't think anyone wants to do this.
I think we need to divide the big pile of modules into groups that (1) can be built from scratch in order (2) align with project boundaries
Here's one way to do that:
<snip>geronimo-specs tranql tranql-connector maven xmlbeans plugin geronimo-modules without assembly geronimo plugins except xmlbeans openejb core and builder geronimo applications geronimo assembly openejb assembly openejb itests
<snip>
What do you do to get around the circular dependency?
Hopefully the above answers this question :-). One problem talking about this is that the words module, project, and subproject have too many meanings. I don't have a solution for that problem yet :-)
thanks david jencks
Thanks Anita
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
