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.
I honestly think that we are smart enough people to figure out the details of the internals by looking at the code, the problem is that the code is not all there!
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.
No, I disagree. Carsten is doing what I would like everybody to do: go in there and cleanup what they dislike.
The problem is that nobody knows if they like or not what's in there anymore... they just use it, they write thousands of scripts to install and remove their blocks, while a regexp-based include would make all those scripts obsolete and help out!
On the other side, I agree with Daniel: blocks were all or nothing. They were not design with incrementality in mind and it shows.
Something that doesn't help also is the fact that our foundations are maintained and documented (or not) elsewhere, at Excalibur.
Yes, this is severely hurting us, IMO.
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?
+100000000000000
What I would like to see is a repository of all the code that we depend on, in one convenient location, say
http://cocoon.apache.org/2.1.6/java/org.apache.blah.Blah
and that returns you the right version of that file... then we can write an eclipse pluging and make sure that everytime you hit a class, that code gets fetched.
This approach *does* have incrementality.
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.
I think that documenting the 'best approaches' for how to write your code in cocoon and how to find the information you need, is going to be enough to get people excited again.
Myself first :-)
-- Stefano.
