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: [RT] a simple release plan
Date Fri, 17 Mar 2006 13:11:11 GMT

Upayavira schrieb:
> Andreas Hochsteger wrote:
>> Daniel Fagerstrom wrote:
>>> Ralph Goers skrev:
>>>> Andrew Savory wrote:
>>>>> Hi,
>>>>>
>>>>> Ralph Goers wrote:
>>>>>
>>>>>> 1. I'm pretty sure all the blocks have not been mavenized.
>>>>> Is there a list of blocks to mavenise anywhere, with instructions of
>>>>> how to do it? I don't mind helping with this.
>>>> The easy way to tell I suppose is to check out trunk. There are a
>>>> bunch of cocoon-whatever directories. Compare that list with what is
>>>> in src/blocks in 2.1.  I believe the instructions are in
>>>> README.m10n.txt.
>>> Actually all the trunk blocks
>>> http://svn.apache.org/repos/asf/cocoon/blocks/ was Mavenized once.
>>> Then two things happened:
>>>
>>> 1) We decided to change to change directory structure to something
>>> that followed the Maven standard, and that had some other advantages:
>>> http://cocoon.zones.apache.org/daisy/documentation/g1/756.html. All
>>> blocks with the new structure are moved to the trunk.
>>>
>>> 2) We changed group id from apache-cocoon to org.apache.cocoon (in
>>> trunk). As the later is the recomended structure for M2.
>>>
>>> Most of the blocks in http://svn.apache.org/repos/asf/cocoon/blocks/
>>> would probably build again just by fixing the group id.
>>>
>>> It would of course be nice to switch all to the new directory
>>> structure, but that can be done one block at the time when someone
>>> feel the itch.
>>>
>> Is there something that persons without SVN access can help with?
>> The instructions for the m10n of Cocoon Blocks require SVN access for
>> moving directories and files.
>>
>> Nevertheless I'd be glad to help by providing patches via Jira, if
>> somebody could tell me what might be doable for me.
>>
>> I already was able to build the trunk with Maven and run the Welcome
>> page - but without samples so far.
> 
> The subversion part is the easiest bit. Working out exactly how to make
> it work is very useful and doesn't require SVN commit rights. Although,
> if you do move directories, try using svn move, as it will likely make
> for better svn patch or svn diff output at the end of the process.
> 
> Personally, I would say go for it. Anything anyone can do would be
> great, and is much needed right now.

Thanks, Upayavira!

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.


> Regards, Upayavira

Thanks,
Andreas

Mime
View raw message