cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Is Cocoon unstable?
Date Wed, 07 Aug 2002 13:54:50 GMT

Jens Lorenz wrote:
>
> ----- Original Message ----- 
> From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
> To: <cocoon-dev@xml.apache.org>
> Sent: Wednesday, August 07, 2002 2:05 PM
> Subject: RE: Is Cocoon unstable?
> 
> 
> > Jens Lorenz wrote:
> > > 
> > > I've to agree on this. Instable not with the meaning of crashes
> > > but with the meaning of fast changes of API interfaces.
> > > 
> > > I can even come up with a quite good example.
> > > 
> > > The move of the Source interface from Cocoon to Excalibur.
> > > 
> > OK, I agree with you - only partly - because these are changes
> > between the 2.0.x series and 2.1. As 2.1-dev is called alpha
> > it's not intended for production environments.
> 
> You're right. But I would distinguish between production and
> development. There are enough improvements for me to use
> 2.1 for research and development, and use 2.0.3 for production
> and projects.

Ok, I agree - we do the same...

> For example inputmodules together with sitemap integration
> are a great feature, which also would fit into 2.0.x.
> (AFAIR InputModules are in scratchpad for 2.0.x but not
> integrated with sitemap, not even with TreeProcessor)

Now, the problem is: time and resources. New features have to be
added with great care not to break anything. And sometimes new
features require "core" changes or some decisions were simply
wrong etc.
So on the one hand side we must be able to deliver bug-fix
releases and on the other hand we want new (perhaps incompatible)
features.
This is with branching, merging etc. no problem. But this is
an OS project, so everything depends on the community. If the
community acts "rather slow", then it will take time for the
next major release (2.1 in our case) - if we would have enough
resorces, 2.1 would be out the doors by the end of august
with compatibility layers, documentation etc.

> 
> > > For our document managment system we invented and extended
> > > Source interface with some extra functionality. So that we
> > > could integrate nicely with existing components (generator
> > > and reader in particular), but use extended functionality
> > > by just doing "instanceof ExtendedSource".
> > > 
> > > Our source still works with 2.1, but since it is wrapped up
> > > in another compatiblity class the instanceof statement fails.
> > > Even worse, there is no way to get at our wrapped (old) Source.
> > > 
> > > One solution we've developed is to create a (JDK 1.3 only)
> > > dynamic proxy which replaces the Wrapper classes and still
> > > implements all interfaces of the wrapped Source thus allowing
> > > it to be used the old and the new way.
> > > 
> > > Another solution is to develop a new ExcaliburSource, but this
> > > way we're unable to use it with 2.0.x. It doesn't even compile.
> > > 
> > > So essentially we've to maintain two versions. One for 2.0.x and
> > > one for 2.1.x. (and that's a PITA)
> > 
> > Ok, agreed - if you have any suggestions how to improve the wrapper
> > classes to avaid such problems, let us know.
> 
> Will submit a patch with short description via bugzilla. Probably
> needs a bit polish and works only one way, but works as a basis.

Great!

> 
> > > And the Source is only one example. 
> > > Another is Loggable vs. LogEnabled.
> > > 
> > Loggable still works and will work in 2.1 - so no need to upgrade.
> 
> LogEnabled is great since I could use Log4J then and log to the
> syslog facility and mail admins upon fatal errors.
> 
Yes, and of course you can use LogEnabled - but it is not required to
rewrite your components.

> > I understand your concerns and know that this is a PITA, but it has
> > nothing to do with an unstable 2.0.x series - and that's what I'm
> > currently focusing on.
> 
> Well, updating an application from one 2.0.x to the next version
> took days as well. We've had this from 2.0 to 2.0.2 and from 2.0.1
> to 2.0.2.
> And the errors were more subtle than just a missing method during
> compilation. Can't remember a particular one though.
> 
Hmm, that's interesting, because the 2.0.x series should be compatible
and therefore compile problems should not occur. 

> > If there are such hard upgrade paths for upgrading to 2.1 (which is
> > still alpha, so I stronlgy suggest to not upgrade) then we should
> > detect them and provide solutions for it (at least when 2.1 hits beta).
> 
> Agreed.
> 
> > The wrapper classes for the source objects are one step.
> 
> Will come by BugZilla.
> 
Thanks, again.

Carsten

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message