Return-Path: 
 <dev-return-85497-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 36513 invoked from network); 17 Mar 2006 14:22:18 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 17 Mar 2006 14:22:18 -0000
Received: (qmail 42555 invoked by uid 500); 17 Mar 2006 14:22:05 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 42479 invoked by uid 500); 17 Mar 2006 14:22:04 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
List-Id: <dev.cocoon.apache.org>
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 42468 invoked by uid 99); 17 Mar 2006 14:22:04 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Mar 2006 06:22:04 -0800
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Received: from [217.12.11.32] (HELO smtp001.mail.ukl.yahoo.com) (217.12.11.32)
    by apache.org (qpsmtpd/0.29) with SMTP; Fri, 17 Mar 2006 06:22:03 -0800
Received: (qmail 96050 invoked from network); 17 Mar 2006 14:21:42 -0000
Received: from unknown (HELO ?10.4.1.249?) (reinhard?poetz@86.59.20.138 with
 plain)
  by smtp001.mail.ukl.yahoo.com with SMTP; 17 Mar 2006 14:21:42 -0000
Message-ID: <441AC5F1.4070101@apache.org>
Date: Fri, 17 Mar 2006 15:21:37 +0100
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Script for m10n of blocks (was Re: [RT] a simple release plan)
References: <44183A19.5080908@apache.org> <441880E3.90303@nada.kth.se>
 <4419812E.5010404@apache.org> <44198C1E.8000003@dslextreme.com>
 <44199130.9000503@luminas.co.uk> <4419A9FA.4060401@dslextreme.com>
 <4419DAA7.7070105@nada.kth.se> <441A8891.4050402@student.tuwien.ac.at>
 <441A96C1.9020406@odoko.co.uk> <441AB56F.7080104@student.tuwien.ac.at>
 <441ABF6B.6040303@apache.org> <441AC315.9080809@student.tuwien.ac.at>
In-Reply-To: <441AC315.9080809@student.tuwien.ac.at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

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