cocoon-dev mailing list archives

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


What I would like to see is a repository of all the code that we depend 
on, in one convenient location, say

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 :-)


View raw message