On Sunday, Sep 14, 2003, at 20:51 Europe/Rome, Vadim Gritsenko wrote:


Stefano Mazzocchi wrote:


On Sunday, Sep 14, 2003, at 18:31 Europe/Rome, Vadim Gritsenko wrote:


if you wish to have proper names, that would be a comman line property away. This, for example, is useful for those projects that might wish to still distribute a complete war (forrest comes to mind) where the wiring.xml file is generated at build time.


So the answer will be then: those directories are generated during build time.


It is entirely possible to create a build process that creates the wiring.xml file without using the block deploying tool. I think cocoon apps like Forrest/Lenya might want to choose two types of distribution: a big war with all the blocks pre-expanded and the wiring.xml generated at build time and another one as blocks to be deployed on top of an existing cocoon.


But would it be possible to provide big war with blocks not-expanded in the predefined directory [1] and with no wiring.xml generated and have deployer work it's magic?

why? isn't it easier to provide a wiring.xml already built?


Once such war is deployed, blocks unpacked and wiring xml generated (possibly with human intervention as you mentioned below) by the deployer tool, you get to the point were you can just zip everything up again and have "a big war with all the blocks pre-expanded and the wiring.xml generated".

the deployer tool is not something that is run when the war is expanded and is *NOT* something that cocoon should have access to (at least, in its default CLI incarnation) [mainly for security reasons]


We can either provide block deploy directory which will not be dependent on container behavior (like we allow specifying work directory in web.xml), or provide block temp directory.


well, which is what we do with WEB-INF/blocks/, don't we?


Which brings us to square one: what will then be the directory (marked with [1]) for the not-expanded blocks? Is it the same directory or is it different directory?

My point is: there is no need for non-expanded blocks to be held on disk.


BTW, I have the impression I'm not understanding what you are aiming at. Instead of discussing the solution, can you point out the problems you see first? I think that would help me understand because at the moment, I'm not sure I do.

--
Stefano.



Reply via email to