cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Issues with chaperon
Date Sat, 05 Apr 2003 20:14:51 GMT
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.



Mime
View raw message