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.
The first distribution is for those who don't have a cocoon already installed, the second will be for those who do.
Is there a way to drop in block into expanded war and have block deployer pick it up?
It could be possible, but only if there is no polymorphic behavior associated to the dependencies of that block. Otherwise, human intervention to choose which block implementation would implement the required block behavior cannot be avoided.
Deployer will have to then pick up block from some directory, generate 123456789 directory, and unpack block there, all in runtime, after the build time.
This is entirely possible, but, as I said, only if there is no need for human choices which are:
1) polymorphic implementation choice 2) deploy-time configuration
The process can be automated, but not as much as for WARs because WARs are much less capable than blocks.
Unpacked blocks: Good question -- maybe in WEB-INF/blocks ?
I'd suggest to store blocks in WEB-INF/blocks/, and unpack/wire/etc them into $temp/blocks, where $temp is temporary directory configured in web.xml. WEB-INF/blocks/ can also have blocks.xml to point out to blocks which are located outside of the blocks directory, for development needs.
that might be a solution, but would force us to consider blocks "read-only" because, otherwise, if a block writes something on its internal file system, that content is not guaranteed to be >> persistent.
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?
-- Stefano.
