Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
IMO our huge community problem is what is most important. No, I'm certainly not talking about our excelent existing community, I'm talking about the fact that we only elected two new committers during 2004, compare that to around ten during 2003, and probably similar figures the years before that. Are our requirements on new committers to high? Maybe, maybe not, I think the standards have been high all the time.
Daniel is right in identifying a transition in our development model and I think I know why this is and has very little to do with block (even if that's important too).
<snip/>
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!!!
I agree with all the things you said, and today's Cocoon is so powerful and so productive that hacking together an application is fast, very fast and many people don't see the need to go down to Java code and/or consider its distance with scripting techniques too high both in terms of verbosity and try/fail period.
A script-like Java leveraging the compiling classloader would certainly help, but it's not enough, since just as you say yourself, you cannot find your way in that code as soon as it's a bit in Cocoon's internals.
So one big problem again here is documentation. Not user-level docs that has been identified as a problem for long an which is currently considered seriously thanks to Reinhard, but developer-level documentation. We can reasonably suspect that many potential developers try to find they way in the code but go away because the internals are poorly documented. And this includes both source-file docs (javadocs & comments) and higher-level big pictures.
Core developers (is there only Carsten and I?) need to pay special attention to this rather than quickly hack some new code. And yes, in this regard, Carsten's effort in the component container, although certainly valuable, seems to me to go in the wrong direction as nothing is being discussed.
Something that doesn't help also is the fact that our foundations are maintained and documented (or not) elsewhere, at Excalibur. This includes the Avalon framework interfaces and SourceResolver, Store, XML utils, etc. Only the framework API is available online. So, should we copy the javadoc of Excalibur component & frameworks we use in our own repo to make this information more accessible?
Another point to consider also is the background of Cocoon users. As new developers are often advanced users that started contributing, we can give an orientation to Cocoon that will attract Java developers and not only "script junkies" (no offense intended). A way to achieve that may be to make Cocoon more "TheServerSide-compliant" (I'm not writing "J2EE-compliant" as Cocoon is deviant in this regard), i.e. integrate more closely with tools that are the current trends in the Java developers community such as Spring, Hibernate (damn LGPL), AOP, etc and show them that Cocoon really rocks for them too.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
