<SNIP/>
I agree with most points from Stefano and we see it each time we do Cocoon training that it's very hard for new users to start with Cocoon. Imho that's a main difference between Cocoon and other projects: with other projects it's very easy to start, but you might get stuck later on in your project. With Cocoon it's very hard to start but as soon as you get how it works, you're very fast. In our trainings we see this as students start to understand most parts on the second day and start having fun and get "productive".
Yes, documentation isn't the best and a starter's guide would imho help here. Adding new features most often comes with no documentation, so while the code base is growing the docs are not.
I have the feeling that we leaned back in the last years saying "we are the coolest on earth" while we absolutely ignored that the world around us changed/moved on: people started using different things like Spring, Hibernate and AOP. And because of our nice "winter sleep" we are now way "behind" other solutions in some areas - of course we are still ahead in some other aspects. I don't say that we should just do it the way others are doing it, but we should go through the world with open eyes and should listening.
When you're doing a lot of projects with people involved that don't have
that deep knowledge of Cocoon, you soon see what would help them: there are two main topics: building and configuring - there are so many different ways of building Cocoon; I guess each of us has his own best practice and don't provide one single solution to the users. Just look at the wiki and see how many solutions are listed there.
So we have identified a lot of different issues that could be fixed. BUT what are we really doing against it? We are endlessly discussing things since years: how things *should* be, how things *could* be etc. And the discussions end most times with everyone nodding his head "YES, that's it, we *really should do this*". And then everyone just goes home and hopes that someone else is doing the work.
But obviously just discussing things doesn't fix anything - so we need people doing something apart from just discussing. And imho it doesn't matter if during the development Cocoon isn't working for some days or if a feature is added that isn't that optimal. We are talking about our "trunk" which is our development branch; so we can do whatever we want there and if we think that something shouldn't stay there, we can simply remove it. We don't have to take care of potential users of the trunk. With 2.1.x it's totally different of course, we should be very carefully when adding/changing things there. We *never* should introduce incompatibilities there.
So, my opinion is we should just look at what people want to use, what
*we* thing is the best to have, combine those two and then: just do it.
The past showed that first discussing things lead to no code while first
coding somethings and then start a discussion based on the code works
very well. Even if the code is totally changed or removed, it seems to be the better way.
And this is what I'm currently trying to do: I'm doing a lot of projects with Cocoon and I'm talking to many users of Cocoon. While they use Cocoon in different areas, they all have the same problems and even we - working with Cocoon for nearly 5 years now - have similar problems. So I'm taking the feedback, add my own thoughts and implement ideas to see where this may lead. With the current core we have a good base to implement new things. It's our own code and we can add new features like AOP or JMX support there without any problems.
But if I have to discuss each and every feature with 20 people - everyone having it's own ideas - I'm most times blocked: 5 people like the idea, 3 people don't like the idea and so you're doomed.
And please: don't get the impression that I'm saying "I'm the only one doing work in Cocoon and you all are not". That is totally wrong, I'm not the only and others are doing great work in Cocoonland as well. But I can only write about myself, I don't want to point any fingers.
Once Stefano said something about trying to push people out of their comfortable chairs and trying to push them. While I wasn't very happy about that statement when he made it, I think this is what we really need: people doing something.
Real blocks are a very very cool feature. The first time Stefano mentioned it, I wasn't sure if someone really needs it and in fact I was against it. Then Stefano visited us on a nice stormy day in Paderborn and I started to see the potential of real blocks. But although they might help on the long term, I fear the complexity they add. For new users looking at Cocoon, it will become much more complicated and disturbing (at least that's what I fear) - so this is one of the reasons while I'm not that active in that area. I think we should just make little improvements that make using Cocoon much easier.
I still hate flowscript :) When you're used to Java development with Cocoon it's really hard to get your flow script working, because you're using different apis, have different objects, don't have access to specific things (like the object model) and then you start writing a *very interesting code mix* of flowscript and java. So I personally would like to trash the javascript on the server side while replacing it with the Java variant :)
So in the end imho it's really easy: let's work together on the project and improve it. Listen to users and see what you can do about the problem.
Carsten
-- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
