cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Script for m10n of blocks (was Re: [RT] a simple release plan)
Date Fri, 17 Mar 2006 14:21:37 GMT
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.

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Mime
View raw message