cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] How scripting made me hate java
Date Tue, 15 Feb 2005 23:06:04 GMT
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).


> 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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message