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
