Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Agree about not using Castor for the blocks framework. On the same
time it would be better to have a common model, but I don't know how
to best achieve that.
Yes, I was also thinking about this. The best (or even better)
alternative istXMLBeans but that's also far from being light-weight. ...
and JAXB20 requires Java5.
And maybe there is so little in common for the needs in the blocks fw
and the deployer so that it isn't worthwhile.
Yes, I came to this conclusion. AFAIU the blocks framework only needs
read access to block.xml and wiring.xml as by design Cocoon should never
write into these files. If you want to cut the Avalon dependencies (IIRC
you use the ConfigurationBuilder), I would investigate Commons Digester.
But it also comes with a couple of dependencies: commons-beanutils,
commons-logging and commons-collections ... especially the
commons-logging dependency is worring me ...
Digester works good for me, I'm using it on several projects. It's lightweight
enough, powerful enough for most scenarios, and all dependencies are already
shipped with Cocoon anyway.
Commons-logging is used in many places, including tomcat itself, so I don't see
how digester depending on commons-logging makes situation worse - it simply does
not change anything at that point, imho.
Vadim
- Re: Block deployment: working with blocks from a user's... Vadim Gritsenko
-
