> Hi Christopher, > Very good points, but I think this is a discussion that needs to > happen at a higher level. FOP needs to cooperate with Cocoon, and > Cocoon is > committed to Avalon. If Avalon adopted Trunk, or did something similar, it > would fix FOP and Cocoon at the same time with little effort on > FOP's part. That sounds like a good solution for all involved. > I forwarded your message to the Avalon developer's list at > [EMAIL PROTECTED] Does Trunk's licence allow Avalon devs to > mine it for ideas if they don't decide to adopt it unaltered? Yes. We use a variant on Sun's Open Industry Standards Source License (see http://www.openinstitute.org/trunk/license.jsp), which is a fairly "loose" license. Its main restrictions are that those modifications that are made to Trunk itself must adhere to open standards, and/or those standards specified in the accompanying standards document. > Moreover, are > the Trunk team okay with that? The Avalon team does a pretty good job of > giving credit, but sometimes people get upset if they don't totally adopt > their solution. You can subscribe to the Avalon list at > [EMAIL PROTECTED] if you want and I'm sure > they'd like > your input, especially if you were willing to review their > similar proposal. > (and I lost the link to that...) They're very willing to listen. As one of the developers on the Trunk team, I think I can safely say that we do not mind if ideas are mined from Trunk without Trunk being taken wholesale; however, we would appreciate it if the new ideas are fed back into Trunk so that Trunk can be improved. Our main concern is that the addition of Avalon adds a lot of bulk to FOP, unnecessarily. The only use for Avalon in FOP (at least, right now) is the Loggable interface. This definitely, in our minds, does not warrant the inclusion of the entire Avalon library into the mix. One advantage of componentized applications (and frameworks) is that they consist of many loosely coupled pieces, and thus can be split apart into multiple components. If Avalon were split up into multiple very small pieces, and only the pieces that are actually needed (i.e. currently just the logging piece) are shipped with FOP, then we would be happier. This would also help to strictly manage dependencies, not just between applications and Avalon, but within Avalon. We would be happy to start and spearhead an Avalon Trunk project, with the existing Trunk code base if so desired. The idea would then be that it does not depend on much of the rest of Avalon; but rather, the rest of Avalon depends on it. Thanks for reading all this, and we'd love to hear your thoughts! - Eric --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
