Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
<SNIP/>
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, as I already said, I appreciate your efforts and blocks are the
way to go, no doubt. I can only speak for myself, but I see two
advantages of the plan for me (and hopefully for others as well):
smaller changes and getting new features today.
Changing back to the old directory structure, throwing the Maven build
away, and try to get the messy Ant build to work, doesn't seem like such
a small change to me. IMO, making Maven insert some configuration file
and samples into cocoon-webapp, should be a much smaller task. And what
is much more important, it will not split our efforts further or disrupt
the current development.
Furthermore the switch from ECM++ to Spring you performed, without even
bother to cast a vote, was a really large and disruptive change.
The Spring/Avalon core is immature and unstable. Right now calls to
subsitemaps results in NPE:s. Before we got it in at least in a testable
shape I'm against doing any large restructuring of the trunk.
I rewrote the core for
2.2 nearly two years ago and it never went into a release! The same with
ECM++, the configuration includes, the property configurations etc. Now,
we dropped ECM++ in favour of the Spring based container which provides
the same functionality plus Spring. And it makes totally sense to me to
release this as a new version.
Sure, as soon as it is usable again.
There is not much work required for this: if we replace the maven build
with the ant one, we should have a fully working 2.2 with all the new
features. So we only have to move/copy some directories and files and
that's it.
Moving directories is very destructive to do, your suggestion means that
it would be very hard to synchronize blocks in the release and a
"block"-branch. And furthermore I still fail to see why it should be
easier to move around directories than to change some paths in the Ant
build.
Speaking for myself again, I can do this stuff as I know how to
move/copy directories and I now how the 2.2 core works and I'm pretty
confident that it's working pretty well.
Based on what kind of testing do you say that? For me it doesn't work.
But I have no clue about blocks or how to finish the maven build.
You keep saying that you don't understand the blocks. It is not that
much code at all, and we have written tons of descriptions, and giving
talks and tutorials on various levels about it during the years. You
have met me and Reinhard and earlier Stefano IRL plenty of times. I
haven't heard any specific questions about them from you about it.
So are you really interested in trying to understand them?
Remember, I suggested a solution two
weeks ago to get a maven build running, but was told that this is the
wrong way and we should wait for blocks.
I remember that I told you to go ahead. And that Reinhard asked you to
wait because he was close to have a working version of the deployer.
Which he actually had within a week as he said. Unfortunately all the
blocks stuff stopped working after that you changed the core without
running the test cases for the blocks.
And I don't have time to invest
into blocks or maven right now. That's the simple reason for not being
able to help. In addition, the current new core with Spring solves all
my day-to-day problems I have with Cocoon. So why not getting this out?
The core is not your private playground, it is something that the
community owns together. Work in the core require respect for other
peoples work.
And I can't work any further on the core as this always breaks the
blocks stuff, as you kindly pointed out.
I didn't point it out in a kindly way. I was, once again, deeply
frustrated that you break core contracts and the tests for the stuff
that I am developing. If you just did it a few times I would understand
it, but it have happens so many times during the years. And I have spend
so much frustrating work in trying to get things working again.
I don't think that it is to ask for to much that you should check that
the same test cases runs both before and after subtle core changes.
Now, for the latest case with the container switch, I asked you to work
in a branch until the core was stable again. You didn't care about that
and you disrupted mine and Reinhard's work, and the core is still not
working.
So the blocks stuff is blocking
the core development - but the blocking in this place is not really the
problem.
It is not blocking core development, it just means that you need to
communicate before breaking core contracts. The fact that you are
breaking the blocks fw might just be an early indication on that you
changed things that might break less frequently tested blocks and user code.
It seems to me that our community is a little bit "feature-split" atm.
One group wants new features today while the other group wants real
blocks today. I can't tell who's right or wrong and I guess it's unfair
to talk about right/wrong in this context anyway. But I can tell what I
want and more important I know what I can do and where I can help.
Getting a 2.3 out with the proposed plan is doable in the short term imho.
You are free to prove that in a whiteboard branch. But you didn't
address anything of what I said in my last mail, so nothing has changed,
you can still expect a -1 from me if you want to carry through your plan.
/Daniel
