cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: Block deployment: working with blocks from a user's point of view
Date Fri, 13 Jan 2006 16:17:22 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Ok, seems like we need a structured proposal :-)

1. All files needed at deployment time should go into META-INF
    - block.xml
    - block.xconf
    - xconf/*.xconf (includes? do we need more that one .xconf for a
      block?)
    - block.xlog (if we do have logging support)
    - block.xweb (if we need to patch the web.xml; If we need to have
      directives to the servlet container for i.e. security policies,
      additional mime-types this won't work here if we have hot
      deployment of blocks)
    - what else?

2. All file that were NOT supposed to be accessed as normal classloader
    resource (the webapp stuff) go into COB-INF
    - sitemap.xmap
    - **/*.xsl
    - **/*.xml
    - **/*.css
    - and many more

3. The rest are normal classloader resources and belongs to the root
    - **/*.class
    - **/*.properties
    - **/*.xml (i.e. internal config file)
    - I'm sure there are more

WDYT?

Ciao

Giacomo

On Fri, 13 Jan 2006, Vadim Gritsenko wrote:

> Date: Fri, 13 Jan 2006 09:22:06 -0500
> From: Vadim Gritsenko <vadim@reverycodes.com>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: Block deployment: working with blocks from a user's point of view
> 
> Reinhard Poetz wrote:
>>  Giacomo Pati wrote:
>> 
>> >  In Reinhards document it is META-INF/block.xml on the Wiki it's 
>> >  COB-INF/block.xml. So we need to make a decision:-)
>>
>>  Please use META-INF/block.xml, AFAIK we agreed on making our blocks valid
>>  JAR files.
>
> Any zip file with jar extension and /META-INF/MANIFEST.MF entry is valid jar 
> file. Presence of COB-INF can not make jar file invalid.
>
>
>>  The skeleton in my tutorial should be compiled and packaged to an archive
>>  having following content:
>>
>>  /JAR-FILE-ROOT
>>   +-com
>> |  +-mycompany
>> |    +-blocks
>> |      +-myblock
>> |        +-MyCocoonAction.class
>>   +-META-INF
>> |  +-block.xml
>> |    +-com
>> |    +-mycompany
>> |      +-blocks
>> |        +-myblock
>> |          +-pom.xml
>>   +-cocoon-app
>>     +-sitemap.xmap
>>     +-test.xml
>
> Please move block resource files (xmap, xml, etc) into COCOON-INF, or 
> COB-INF, or some such directory, so that:
>
>  a) It is more prominent that these files are not part of
>     'cocoon-app' Java package
>
> b) It is more consistent with other J2EE jars (APP-INF, WEB-INF)
>
> c) Naming conflict (when user has cocoon-app package) is impossible
>
> d) Class loader can be configured to filter out our FOO-INF directory
>
>
>>  If we follow the default Maven directory structure as outlined in my
>>  tutorial, the archive will be created automatically for us.
>> 
>> > >  Now to answer your question ;) the position of the .xconf of a block 
>> > >  is defined in the components element of block.xml.
>> > 
>> > 
>> >  Ok, looking at [1] it is defined in the block.xconf file, which is 
>> >  located in COB-INF (or WEB-INF or META-INF respectively). Is that still 
>> >  correct?
>>
>>  I'm not sure where block.xconf should go to. I'd put it under cocoon-app
>>  and not under META-INF. WDOT?
>
> META-INF is fine, I think.
>
> Vadim
>
>
>

- -- 
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDx9KXLNdJvZjjVZARAktJAKDxB3R6MMm3frEAK1MRno/g7opRUwCfU3ss
B8uMowczgtm5pKNypNQgHuY=
=T2D6
-----END PGP SIGNATURE-----

Mime
View raw message