[prev in list] [next in list] [prev in thread] [next in thread]
List: xml-cocoon-dev
Subject: Re: Script for m10n of blocks (was Re: [RT] a simple release plan)
From: Reinhard Poetz <reinhard () apache ! org>
Date: 2006-03-17 14:21:37
Message-ID: 441AC5F1.4070101 () apache ! org
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic