cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <res1c...@verizon.net>
Subject Re: [GUMP] Build Failure - Cocoon
Date Fri, 28 Mar 2003 17:14:03 GMT
In a proper build and runtime environment the dependencies of the 
implementation details of components (like Batik and Xalan or whatever) 
should be isololated from other components, and renaming of modules 
should never be needed. The fact that you're suggesting that shows that 
we are far from that, as you probably realize. Indeed, it is Rhino's own 
lack of proper component design is the very reason that my changes 
cannot now easily be incorporated. I personally don't consider class 
loaders fancy, but I do consider renaming modules to prevent them from 
stepping each other, a hack (although a necessary one, at times).

Regards,

Chris

Sam Ruby wrote:
> Christopher Oliver wrote:
> 
>>
>> In other words the code in cocoondev.org _really_ is Rhino (+ 
>> continuations), not something different, but just an earlier snapshot.
>> The fact that it still has the same name reflects this. To me (as 
>> someone who has contributed to Rhino) it would be a bigger insult to 
>> change the name.
> 
> 
> I not only have Stefano's concern, I have another: configuration 
> management and version control.  Xalan and Batik each have support for 
> Mozilla's version of Rhino.  Both can productively be used with Cocoon. 
>  When things go wrong, who will be in a position to debug the result? I 
> realize that some people believe that fancy class loaders are the answer 
> to all the worlds problems, but there are some cases where it simply is 
> better to avoid the problem altogether.
> 
> Working harder to get the changes back into Mozilla's Rhino is the ideal 
> path.  Failing that, renaming the codebase seems to be the next best 
> solution.
> 
> IMHO.
> 
> - Sam Ruby
> 
> 
> 
> 
> 



Mime
View raw message