cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <un...@hippo.nl>
Subject Re: [cron block] dependency question
Date Thu, 21 Oct 2004 14:51:52 GMT
Carsten Ziegeler wrote:

>Unico Hommes wrote:
>  
>
>>Ok ok, I get the hint ;-) 
>>    
>>
>Oh, that wasn't targetted at you, Unico, but if you have time... :)
>
>  
>

I didn't really feel that it was. It just seems opportune that I take up 
the issue since I raised it. I'll see what I can do.

>>But before I decide to do any work 
>>there is another issue with the blocks build system I'm dying 
>>to resolve. What about having only one repository location 
>>for blocks? I am so tired of all the duplicate effort we have 
>>to do for each and every change to blocks. It shouldn't be neccessary.
>>    
>>
>
>Yes, and it should be simple.
>
>  
>
>>There probably isn't a small amount of work involved to get 
>>it working but I'd like to know exactly what it would take to 
>>byte this bullet. 
>>Some of the steps involved that I can distinguish are:
>>
>>1. Merge/sync the current 2.1.x and 2.2 blocks.What blocks 
>>have the biggest differences between their 2.1.x and 2.2 
>>copy? If there are unresolvable differerences, how to handle 
>>that? Have separate source locations for different versions 
>>in conflicting blocks? Define Cocoon target versions for 
>>individual blocks in gump.xml?
>>
>>    
>>
>We have to finish the syncing, The wiki still lists some blocks
>that haven't been synced yet - but again this is simple work.
>  
>

Ah thanks for the pointer. I see there is plenty I can do in that 
departement.

>Apart from that, some blocks depend (unfortunately) on some internal
>things which have changed between 2.1.x and 2.2. The most 
>prominent is of course XSP. But there are others that now
>take advantage of some new features in 2.2 that aren't available
>in 2.1.x.
>So in the end this is not so easy.
>
>We could start simple. First move blocks that don't have a difference
>and leave the different ones in the two branches.
>
>  
>

Hmm, that doesn't make the build system any simpler, but alas, we can 
clean up after the migration is complete.

>But I would strongly suggest that we first finish syncing, can
>then do a painless 2.1.6 release and then spend energy on
>this issue. I personally don't want to delay a 2.1.6 release
>just because of a broken build system etc.
>
>  
>

That is true. Is there anything holding back a 2.1.6 release btw?

--
Unico


Mime
View raw message