geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: nightly builds -- another perspective
Date Sun, 08 May 2005 01:25:55 GMT
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 
discussion...

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 <djencks@gluecode.com> wrote:
>>
>> On Apr 28, 2005, at 6:32 AM, anita kulshreshtha
>> wrote:
>>
>>>
>>> --- David Jencks <djencks@gluecode.com> wrote:
>>>> I'd like to attempt to clarify one of my main
>>>> points.
>>>>
>>
>> <snip>
>>>     Maven 2 uses 'scope' to limit the transitivity
>> of
>>> the dependency. What is the nature of dependency
>> of
>>> openejb on geronimo compiletime/runtime/testtime?
>> What
>>> 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:
>>
>> <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
>


Mime
View raw message