[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: [RT] a simple release plan
From:       Reinhard Poetz <reinhard () apache ! org>
Date:       2006-03-17 13:53:47
Message-ID: 441ABF6B.6040303 () apache ! org
[Download RAW message or body]

Andreas Hochsteger wrote:
> 
> 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.

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.

-- 
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]