Luca Morandini wrote:
I mean, Cocoon already has some components relying on non-ASL
> libraries (like the SAP ones or the JDBC drivers); had these > libraries to change, ASF wouldn't be able to fork them, hence > resorting to change the Cocoon components, which is what was > to be avoided in the first place.
This underlines, I fear, a more general problem: to make Cocoon
> more powerful it has to interface to as many software packages > as possible, which means it will, in some ways, come to depend > on them.
> risk !As a long-time Cocoon user, I dare to say: the gain is worth the
As an old Apache fart, I'd say nope... Look at HTTPd land, modules relyng on something over which we have some kind of legal troubles with are not included in the distro, not included in the "core", not on our CVS... mod_auth_mysql, for example). I don't think they ever will...
Getting back to the point: in the case of JFreeChartTransformer
> the idea would be to treat it like the SAP components: put the
This community should not rely on my only judgement to evaluate the possible risks of a strategy... (I'm the one who put all those nasty bugs two years ago, and you had to work for 2 years, in more than 30 to get rid of them! :-) :-) :-)transformer in the codebase and leave the non-ASL library out.Does it sound too risky a strategy ?
And please note that already many raised the same issue with the SAPv3 components (I can't find them in CVS, so, I assume they're not going to be "in" until those problems are solved)...
Steven said:
> If license issues do not allow these components to be added to ASF
> CVS, we could look and see whether they could be hosted at
> cocoondev.org (since yes, they would be a valuable addition to
> Cocoon).
And I share Sylvain's point here:
> we voted a cocoon-apps module to host Cocoon-related developments
> that don't belong to the core. And this ultra-specific component
> typically falls in this category.
Well, in the past, our fellow colleagues on HTTPd created <http://modules.apache.org>. I believe that most people would prefer to see a similar solution for Cocoon rather than adding, and adding, and adding stuff to the main CVS tree. And indeed it would solve the "legalities" as well, relegating the problem to the end user...
<ashamed>
AxKIT solved all this mess even before starting... They use CPAN, we
don't even have that... :-( :-( :-( :-(
</ashamed>
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
