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 Re: Script for m10n of blocks (was Re: [RT] a simple release plan)
Date Fri, 17 Mar 2006 15:52:07 GMT

Reinhard Poetz schrieb:
> Andreas Hochsteger wrote:
>>
>> 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?
> 
> hmm, I don't understand what you mean with "put between". The idea is 
> that the web application goes into COB-INF. Meta data and component 
> configuration goes into META-INF. There is no need for a 
> resources/samples, resources/WEB-INF or resources/conf directory.
> 

With 'between' I meant .../resources/COB-INF/samples - sorry for my bad 
phrasing.

But looking at cocoon-deployer-plugin-demo it looks more like the following:
samples -> cocoon-<block>-sample/src/main/resources/COB-INF
WEB-INF/xconf -> cocoon-<block>-impl/src/main/resources/META-INF/xconf(?)
conf -> (? contain *.xweb, *.properties and other files)

I'm still uncertain about the last two directories.
Can you give me some more details (or pointers) which files and 
directories from the old blocks map to the new ones?
Once I have this information I can adjust the script to respect this 
information.


Thanks,
Andreas

Mime
View raw message