We were very picky with Ivelin and his move to factor out xmlform, but I'm going to be as well with Chaperon.
There are few things that I don't like: 1) copyright is given to the ASF. While I *do* appreciate the intention, the ASF's policy cannot allow this (I'm going to be picky on those things, so be prepared in case you host stuff with the ASF copyright which are not hosted on ASF-infrastructure-driven hosts) As a short term solution, I would suggest to change the copyright sign. [the license is fine] 2) chaperon is impossible to add to gump because it imposes circular dependencies. this is a general indication of a bigger problem: chaperon *includes* its own cocoon-dependent classes. this is a big issue: as far as it's nice to see libraries that can be used in other contexts factored out (xmlform, poi, chaperon, fop, batik... we have tons of them), all the cocoon-related components (all those importing org.apache.cocoon.* stuff, for example, should remain inside the cocoon CVS, in this case, into the chaperon module. Why? well, if not, cocoon will depend on chaperon and chaperon will depend on cocoon. And this breaks gump. I'm *SICK* of updating the gump.xml descriptor for everytime the chaperon library snapshot is updated and imported in CVS. Sure, I could keep on nagging Stephen everytime he updates the jar, but this is just an indication of a bigger problem: circular dependencies are evil and show a sign of bad architecture or, in the best case, lack of cooperation. Comments? -- Stefano.
