cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <...@keow.org>
Subject Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Date Sat, 06 Mar 2004 07:05:01 GMT
On Fri, Mar 05, 2004 at 11:41:15PM +0000, Pier Fumagalli wrote:
> On 5 Mar 2004, at 21:10, Stefano Mazzocchi wrote:
> >Tim Larson wrote:
> >>On Fri, Mar 05, 2004 at 01:24:57PM -0500, Stefano Mazzocchi wrote:
> >>> Package: org.apache.cocoon.cforms
> >>>
> >>>here I would go "forms" instead. package naming is where the estate 
> >>>really is, where class collissions might happen.
> >>
> >>I understand how this seems like a good place for the battleground,
> >>but to introduce a new winner it looks like this would force us to
> >>break code compiled against the previous major version because we
> >>would be stealing the class and interface names for the new version.
> >>Does the new block system somehow solve this problem like via
> >>classloaders or something else?
> >
> >eh, very good question, actually. I spent a few hours discussing with 
> >Pier about this yesterday over IM. Pier, as usual, sees the very core 
> >problem and I always miss ;-)

<snip long, complex classloading/dependency discussion/>

Ok, so to sum up the version/classloading discussion, this plan
(using 'forms' for the package naming) involves burning the users
on major version upgrade by for most practical purposes breaking
the previous major forms version when introducing the new version.

I agree with the idea of forcing core developers to choose between
adding enhancements incrementally versus making a *major* effort to
prove that their new revolutionary version deserves to unseat the
current framework, but making things tough for the users is going
too far.  I must be missing something, would somebody enlighten me?

--Tim Larson


Mime
View raw message