-----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 <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
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-----
