cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: [2.2] Dynamic xconf try to open non-existing files (bug?)
Date Sat, 12 Feb 2005 19:02:15 GMT
On Sab, 12 de Febrero de 2005, 10:44, Stefano Mazzocchi dijo:
> Antonio Gallardo wrote:
>> Hi:
>> I updated SVN today. While trying to start the servlet with a small
>> selection of block, the servlet reject to start with this error:
>> /home/agallardo/svn/cocoon-2.2/build/webapp/WEB-INF/xconf/cocoon-velocity.xconf
>> (No such file or directory)
>> I included the velocity block and now the error is:
>> /home/agallardo/svn/cocoon-2.2/build/webapp/WEB-INF/xconf/cocoon-javaflow.xconf
>> (No such file or directory)
>> Seems like the servlet try to open .xconf files of blocks not included
>> in
>> the build.
> I was just looking at that: the block .xconf file now explicitly import
> the configurations they depend on.
> This now requires people to religiously add all the dependencies for all
> the blocks they import, even if such dependencies are used by their
> samples.
> The more it think about this, the more I believe that <imports> should
> not be done explicitly but implicitly, based on some aggregated
> dependency information (for example, the blocks should have their block
> descriptor block.xml and include the dependency information there)
> This will very well be a great transition phase (but still incremental!)
> for a more 'real' block system.

OK. I see the point.

Getting this a little bit more deep, then will be fine to extend this
functionality to the blocks level. For example: If I choose "slide" block,
then automatically the build system should resolve the other dependencies:

jms, databases, xsp, hsqldb
repository, eventcache.

Of course only the dependencies related to the real block usage without
take in consideration the blocks needed by  samples or perhaps will be
enough to see if the samples property is on to include them too.


View raw message