On Tue, 15 Feb 2005 11:37:18 -0500, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
Obviously, it doesn't.... the stacktrace is a million lines long... most of this code I don't recognize anymore, it's like looking at somebody else's project now and it's big and massive. And the logs were all fragmented (I fixed that :-)
So, all right, fix the code in eclipse, change to the terminal, run ant, hit cocoon-reload (twice! that stupid ehcache thing in the way), say "thanks sylvain" ten times (instead of a thousand, that's why you say that ;-), another stacktrace... go back to square one. One modification per minute... and I'm used to one modification every 5/10 seconds in debug mode.
Here I have to agree with Ugo. Unit testing can make a change:
I took one generator, merged it with another, and updated the library that they used (because I needed a new feature) and now it throws IllegalArgumentExceptions.
'unit' testing is about testing units, isolated functional pieces that can be considered passive and tested independently.
Cocoon's internals are *far* from being that kind of unit. You can't test a single method of a SAX content handler, that gives you nothing!
You can test the input and output of a pipeline, but this is exactly what I do with my browser when I hit it! Sure I can automate that when it's ready to know what is broken or not later on, but it's not unit testing, is functional testing... and helps when you are doing modifications, but doesn't help at all when you are implementing new features (or merging different existing ones).
since I
started committing myself to write code which can be tested in
isolation, the number of try/fail cycles has happily decreased. But
this is like watching the finger pointing to the moon:
exactly.
yes, there is a clear issue in the (overly?) complex architecture of Cocoon. My day job is basically promoting Cocoon around, and I'm really used to the "Cocoon is a scary beast" meme: I have developed techniques and tricks to prove the opposite, but I can clearly see how there is a problem and why Cocoon is perceived as a scary beast and/or an academic effort.
It *is* scary. The library dependency chain is 28 levels deep! There are more levels dependencies in cocoon than in a 747 airplane! It took gump 3 years to compile it a single time out of fresh CVS! Some of its dependencies are gone, the sourcecode not even tagged in the code repository (stupid excalibur doesn't tag the component releases!), the javadocs scattered allover, there are libraries in our lib directory that *nobody* knows what they are used for (the pizza compiler, for example) and there are no more than 4 people that ever touched the core in the last 18 months.
Wake up people, the sum of all this is dangerous.
However, I'm also strongly convinced that Cocoon is the most impressive incarnation of rapid development and try/fail cycle when it comes to webapps: there is nothing like Cocoon which allows to develop really complex stuff without even touching Java. Of course there is a price for that: whenever you have to go under the hood, you find an incredible amount of complexity that tends to scare the average developer away.
This is fine. I don't mind that. What bothers me is that it's not cocoon that scares me away, it's the development model induced by it: so simple and rapid on top, so complex and irritating inside.
This gap might prevent us from aquiring new talents, since they will all remain at the scripting level, patching there instead of inside.
Scripting taught me (spoiled me?) with incredible high productivity but I think there is a problem when people are not able to go back and fix the underlying object model that the scripting is a glue for... because it forces people to hack things in their glue layer, which reduces reuse and *prevents* contributions to get back in the system!!!
It's the good old balance, and the hardest line to draw ever: personally I still belong to the party of those who think that the power of a framework is in the amount of guidance that it gives you and in the mistakes it avoids, rather than in the flexibility it allows. I'm not sure I'm technically willing to trade flexibility for protection, but with my community hat on I can see your point. The Cocoon community is alive and kicking, but it resembles more and more a closed circle: Daniel's figures sure made me wonder.
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.
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?
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. 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.
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.
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.
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.
Ciao,
-- Stefano.
