> 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, email: [EMAIL PROTECTED]
