cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] a simple release plan
Date Wed, 15 Mar 2006 21:02:27 GMT
The blocks FUD
==============

I'd like to remind once again that the blocks work doesn't destabilize 
the traditional use of Cocoon the slightest, see 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=114073731515724&w=2. It 
just cannot affect that as there are no dependencies from the 
"traditional" parts to the blocks fw whatsoever. Concerning the OSGi 
stuff it is not even part of the build yet.

So the idea that the block work should hinder anyone to work as usual is 
just plain wrong.

M10N
====

What hinder people to work as usual is that the M10N isn't finished. Now 
it isn't that hard to use Cocoon anyway as I described in the reference 
above. But of course it would be nicer to be able to use Cocoon with 
some blocks OOTB. If you don't want to take part in working on the 
blocks fw and deployer and is impatient, it wouldn't be that hard to 
write a plugin or an Ant task called from Maven that does the file 
copying that is described in the reference above.

BTW, I'm quite surprised that you want to go back to the messy Ant build 
from 2.1.x after having argued for building Cocoon with Maven for years. 
Have you lost your faith in Maven?

Springification
===============

Talking about destabilizing, a couple of weeks ago the trunk was usable 
after the file copying referred to above. Actually it was so stable that 
I developed a small customer application with it without any problems. 
And AFAIU Reinhard have developed a large application in it. This is not 
the possible anymore, after the Springification.

I tried to start a freshly checked out trunk together with the ajax, 
form and template block after having copied the configuration files and 
samples to cocoon-webapp as described above. The start page worked, but 
all access to sub sitemaps gave null pointer exceptions, where the 
TreeBuilder configuration can't be loaded. IIRC there where other things 
that was reported that didn't work a couple of weeks ago as well.

I suggest that the container should be reasonably stable before even 
thinking about doing any big moves.

            --- o0o ---

Not surprisingly I'm -1 on your points 2 and 3. If you want to continue 
in that direction which IMO represents a huge step back. I insist on 
that you prove that it work and that you actually have the persistence 
to carry it through, on a copy of the trunk in the whiteboard. After 
that you need to cast a vote about making that the new trunk.

Also it should be much easier to update the Ant scripts than changing 
the directory structure.

Anyway, why you would like to make such a huge effort in such an 
backward pointing direction, instead of helping to finish the blocks 
work or at least the M10N, is just beyond my imagination.

/Daniel

Carsten Ziegeler skrev:
> Ok, here is a simple plan to continue.
> 
> Please note, that the current trunk has several new things: a new core
> which can be seen as a follow-up to 2.1.x, the blocks stuff and the
> maven build. We can use trunk as a direct follow-up to 2.1.x without blocks!
> 
> As Bertrand suggested we should start with a "fresh" version number:
> 2.3. So the plan looks like this:
> 
> 1. Release 2.1.9 by the end of march as discussed recently
>    This includes freezing 2.1.x and really just doing important bug
>    fixes there.
> 2. Copy trunk to a new place to continue the blocks development
> 3. Remove blocks stuff from trunk and use it as a base for 2.3
>    This includes: using the directory layout from 2.1.x and using
>    the ant build sytem from 2.1.x
> 4. Sync 2.1.9 and 2.3: there are only a few things which still need to
>    be synced.
> 5. Release 2.3m1
> 
> At the same time the blocks stuff can continue and we are not blocking
> any development.
> 
> WDYT?
> 
> Carsten


Mime
View raw message