cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Hochsteger <e9625...@student.tuwien.ac.at>
Subject Script for m10n of blocks (was Re: [RT] a simple release plan)
Date Fri, 17 Mar 2006 14:09:25 GMT

Reinhard Poetz schrieb:
> Andreas Hochsteger wrote:
>> I mocked-up a shell script which converts the directories from the 
>> "old" blocks to the structure used by the "new" mavenized ones.
>>
>> Don't expect too much, since there is still some more manual work to 
>> do, but at least some easy parts can be automated this way.
>>
>> It handles the following directories from the old blocks:
>> * java
>> * test
>> * conf
>> * WEB-INF
>> * samples
>>
>> Currently the directories are only copied and not moved via 'svn mv'.
>> I wrapped the commands for moving directories into the function 
>> MoveDir() which can be adjusted to perform svn operations.
>>
>> The converted directory structure looks like this (<blockname> refers 
>> to the directory name of the old blocks):
>>
>> cocoon-<blockname>
>> +-cocoon-<blockname>-impl
>> | +-src
>> | | +-main
>> | | | +-java ('java' from old blocks)
>> | | | +-resources
>> | | | | +-WEB-INF ('WEB-INF' from old blocks)
>> | | | | +-conf ('conf' from old blocks)
>> | | +-test
>> | | | +-java ('test' from old blocks)
>> | +-cocoon-<blockname>-sample
>> | +-src
>> | | +-main
>> | | | +-resources
>> | | | | +-samples ('samples' from old blocks)
>>
>> It would be great if somebody can have a look at it, if I got 
>> everything right.
>>
>> Next step would be to adjust MoveDir() for svn operations and to 
>> handle pom.xml.
>> I don't know if the handling of pom.xml can be easily automated, since 
>> it has to be split into 3 pom files.
> 
> Andreas, thanks for getting involved! Your work looks good; could you 
> please make some changes to the directory structure of the "new block"? 
> What we need is a structure as used in "cocoon-deployer-plugin-demo":
> 
> src
>   main
>     java
>     resources
>       COB-INF --> the webapp here (e.g. samples)
>       META-INF --> component configurations here
> 
> This is the right structure for "real blocks". In order to satisfy our 
> current needs of deploying into a web application that does *not* use 
> the blocks-fw, we can extract the JAR into several places from within an 
> Ant script or a Mojo:
> 
> COB-INF        --> [web-app]/samples
> META-INF       --> [web-app]/WEB-INF/xconf
> the JAR itself --> [web-app]/WEB-INF/lib
> 
> It shouldn't matter that we use the "new" structure.
> 

Thanks for the hints.
Do I understand it right, if I put COB-INF between resources/samples and 
META-INF between resources/conf and resources/WEB-INF.
The rest stays as  I suggested it?

Andreas.

Mime
View raw message