cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [Heads up] Change to build system in 2.1.x
Date Mon, 25 Oct 2004 22:42:22 GMT
Vadim Gritsenko wrote:

> Stefano Mazzocchi wrote:
> 
>> We really gotta start thinking about our build system and gump 
>> integration.
>>
>> Vadim Gritsenko wrote:
>>
>>> Unico Hommes wrote:
>>>
>>>> I've completed the changes to the build system discussed earlier 
>>>> [1]. In order to do so I have extended the gump descriptor with 
>>>> additional information that allows the build system to locate one or 
>>>> more dependency jars per <depend> project within ./lib/optional. See

>>>> for an example the cocoon-block-axis project definition in gump.xml
>>>>
>>>> Every block now *must* declare all the dependencies it requires to 
>>>> compile in gump.xml just in order for it to build properly.
>>>>
>>>> Since I am not very familiar with gump.xml and I had to add a lot of 
>>>> information it is very probable that I made a mistake or two with 
>>>> the way local projects are declared.
>>>
>>>
>>>
>>> I thought you'll add <libary/> element which would be independent of 
>>> <depend/> element and thus avoid any possible conflicts with Gump. 
>>> But now I see that you'd added bunch of new <depend/> elements - 
>>> which are not currently required by Gump - I don't think we should do 
>>> that.
>>>
>>> I'd sleep better if instead of:
>>>
>>> +    <depend project="db-ojb"/>
>>> +    <depend project="antlr"/>
>>> +    <depend project="commons-dbcp"/>
>>> +    <depend project="commons-pool"/>
>>>
>>> We'd have:
>>>
>>> +    <library project="db-ojb"/>
>>> +    <library project="antlr"/>
>>> +    <library project="commons-dbcp"/>
>>> +    <library project="commons-pool"/>
>>
>>
>>
>> this will make our descriptor being invalid, but since I control the 
>> DTDs we can change that on the other hand.
>>
>> but there is something that bothers me: the above really doesn't make 
>> any sense. What would be a lot more useful would be something like
>>
>>  <depend project="antlr" version="1.0"/>
>>
>> or
>>
>>  <depend project="antlr" timestamp="20040349"/>
>>
>> or
>>
>>  <depend project="antlr" tag="V1_0_RELEASE"/>
>>
>> then it would be up to gump to give you the version you want (and we 
>> might indicate what versions we expose in our gump.xml description).
> 
> 
> Two points;
> 
>  * Gump is about continuous integration, i.e. always trunk, right?

so far ;-)

>    And our build does not need version information too. Then,
>    who needs it?

My idea is the following: gump should be *both* a build system and a 
continous integration system. It should build your project in two phases:

  1) run against the dependencies with the versions you specify (since 
they will never change, they can be built once and their packages kept 
in place forever). If broken send nightly build error and stop.

  2) if nightly built was successful, perform continous integration by 
running against the latest and greatest. If broken, send continous 
integration warning and stop.

>  * gump.xml currently does not record dependency on antlr. Do you think
>    it should be added? 

yep.

> Why? 

see above.

> That's what I meant above - I'm not sure
>    we should add bunch of dependencies.
> 
> Another issue is that dependency project name might not match library 
> name...

well, that's your concern only if you specify the version (and, even in 
this case, it's enough to create a mapping between a version and a 
tag/timestamp).

If you specify a timestamp or a tag, gump can figure it out by itself 
since it has all the metadata it needs to figure out where the builds 
write their jars and how they name them.

Hope this helps.

-- 
Stefano.


Mime
View raw message