Talking about this is somewhat difficult due to the multiple and
overlapping meanings of project, module, and subproject (at least).
So, I'm going to arbitrarily define, for the purposes of this
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
So, the purpose of having subprojects is to enforce more structure on
the project than given purely by modules.
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.
> --- David Jencks <[hidden email]> wrote:
>> On Apr 28, 2005, at 6:32 AM, anita kulshreshtha
>>> --- David Jencks <[hidden email]> wrote:
>>>> I'd like to attempt to clarify one of my main
>>> Maven 2 uses 'scope' to limit the transitivity
>>> the dependency. What is the nature of dependency
>>> openejb on geronimo compiletime/runtime/testtime?
>>> about 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:
>>>>> maven xmlbeans plugin
>>>>> geronimo-modules without assembly
>>>>> geronimo plugins except xmlbeans
>>>>> openejb core and builder
>>>>> geronimo applications
>>>>> geronimo assembly
>>>>> openejb assembly
>>>>> openejb itests
>>> What do you do to get around the circular
>> 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 :-)
>> david jencks
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
|Free forum by Nabble||Edit this page|