Damn, hit send too soon :-)
Stefano Mazzocchi wrote:
People keep talking about documentation.... but let's get real: we know that the code is the place to look, you can 'control-click' in eclipse on a method and see what it does, you don't need documentation if you are a cocoon committer to stop being afraid.
The documentation will never be good enough... but the code can be improved too!
> I'm in *desperate* need to reduce that try/fail cycle in cocoon or I
simply won't be able to touch its code anymore. Which is very frustrating, given the amount of things I could get done if I only could go back to it.
Believe me, 95% of the time the try/fail cycle in Cocoon is the shortest ever, since you don't touch a single line of Java code.
I agree.
Dynamic compilation might fill the remaining space, helping people getting back to Java, but are we really sure this is what we need when the real blocker is the frightening learning curve whenever you have to go past a simple sitemap component?
No, and I don't care.
This is *NOT* what I'm trying to solve. I don't care if users user java or not, what I care is that cocoon committers are not afraid of the core or that they are not adding java components to the system because writing them in javascript is faster and easier (been there, done that).
I want to make it easier to go back into hacking cocoon itself, because innovation is happen on the outside and I think this is dangerous in the long run to the solidity of the internals.
The Cocoon core is clearly at risk of collapsing because of its
complexity: unfortunately the only solution I can foresee is the clean
slate one, AKA Cocoon 3.0.
No, no way. Not the 2.0 syndrome over again.
And even then, I don't really think it will be that easy to build an understandeable machinery: we are doing complex stuff, and it's impressive the amount of complexity we managed to hide to the user. I'm not sure that things like environment handling, context switching, continuations machinery and sitemap interpretation can be more accessible than they are now.
Agreed.
Not only that: my gut feeling is that even other frameworks (Struts, Tapestry) have a complex inside machinery: their advantage is that the perceived complexity is much lower and the user doesn't ever need to fire a Java IDE. I think that's the case for Cocoon as well, but this is not the common perception.
For one thing, they don't depend on 218 libraries :-/ which also means they are way less powerful.. but power comes with a price.
Here blocks will help tremendously.... yet we need to 'aggregate' the source code + javadocs in one place because our own internals are scattered around many projects, some of which dead and some of which sleeping.
So, in the end, I see two main issues compromising the future of Cocoon: entry barrier for new users and learning curve for core developers. How to solve both? Well, for users it all boils down to usability improvements, clear guidance and toolsets: for one, the configuration system as it stands now is a sore pain. What seemed to be a good thing (using the role shorthand as the main configuration element) ended up in a real mess of undocumentable, unvalidatable and un"tooleable" XML blob: <component-instance> all over the place could have been less readable, but in the long run it could have been much more manageable. And if you think about it, this is FS biting us hard: a more rigid configuration system could have brought us a set of tools to manage our needingly complex configuration system.
Agreed, but honestly I'm not concerned about users... because that's what everybody is concerned about... and where the money is, so things will improve.
Developers are different. There is no way on earth you can turn sky-high challenges into blatantly simple code, but at a very least you can make it interesting. The Cocoon core isn't sexy anymore: people wants easy isolation development, testing tools, up-to-date IoC techniques and, most of all, they don't want to have to learn a ton of non-standard technologies just to itch their own scratch. The clean slate, if ever going to happen, should take all that (and possibly more) into account. As you can see, I sincerely believe that the java try/fail cycle is really just a small corner of the overall picture. But yes, we have a problem.
The cocoon core isn't sexy and its million-lines-long stacktraces don't help at all.
Also, having dependencies on a million little jars, api and impl, each with 3 classes each is stupid, brain damaged, a thing of the past, the ultimate overdesign and abstraction masturbation.... and the are no docs about those, no javadocs, no browsable source code with the right version number.
It's ridicoulous.
But starting over is creating more problems than it solves.
I have an itch to scratch: I want to be able to work on and in cocoon, in java, with the simplicity and productivity of a scripting language.
This requires me to have all the dependent source code + javadocs available at my (eclipse-powered) fingertips, or I won't be able to do it.
This also requires me to have 'development' strategies: where to place my code, how to reload fast, how to inject changes at debug time using hot code (thanks Vadim, but for some reasons it doesn't work on a mac :-( still investigating), how to make eclipse compiled classes be picked up by the cocoon classloader, how to deploy remove my blocks, my code and my libraries... and so on.
No classloading isolation, no hot deployment, no transparent proxying of polymorphic aspects, nothing fancy: just more flexibility and a well designed (and documented) development workflow for committers, that users can use to become more 'powerful' users (would their need emerge).
And we'll see people going back to code in there... and hopefully the dust will be removed a little bit at a time, just like Carsten and Sylvain are already doing.
-- Stefano.
