cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [proposal] a new kind of 'dist'
Date Mon, 24 Mar 2003 15:38:34 GMT
Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:

>> Yes. This is going to be even more with the introduction of the flow 
>> since people with client-side knowledge (html + css + javascript + xml 
>> + namespace + xslt) will be able to write full-blown web applications 
>> with database connectivity *without* a single line of a language they 
>> don't know nor understand.
>>
>> This is potentially *HUGE*. Yet is a community shift that might find 
>> *ourselves* not-prepared to stand the flood of those people and their 
>> mindsets because most of us don't come from that background and people 
>> in that client-side-web background have no notion of SoC, IoC nor any 
>> abstract concept like OOP, COP or AOP, nor even the most basic design 
>> patterns.
>>
>> This cultural clash is potentially *very* harmful for both sides if 
>> the mindset transition is not done smoothly. 
> 
> Very clever analysis, which resonates with my view of the evolution of 
> software engineering since Java (or the web ?) appeared. The world of 
> "developpers" is more and more split in two categories those who build 
> components or frameworks, and those who use it. This is nothing new
> compared to other domains of the human activity : you have house 
> builders and brick makers, you have electronic device designers and chip 
> makers, etc.

I usually call it 'separation of concerns', even heard of it? :)

> And Cocoon offers so high-level abstractions that people can use it 
> without caring about what's going on under the hood, even not caring 
> about Java.
> 
> Well, almost without caring, since Cocoon is sometimes a leaky 
> abstraction [1] ;-)

eheh, true :)

>>> - they may be installing java for the first time, which (because of 
>>> sun's windows installer) may have no idea what JAVA_HOME is or should 
>>> be.  They'll need to know this regardless, we just have to add even 
>>> this to the list of hurdles they already need to jump.
>>
>>
>>
>> for windows, the sun's installer copies java.exe in the PATH, so we 
>> need to have them set JAVA_HOME *ONLY* if there is no java.exe 
>> available in path. 
> 
> 
> 
> Be careful : what sun's installer copies into the PATH is a *JRE* and 
> not a JDK, which means you have no compiler. So they will end up with 
> something like "NoClassDefFoundError: com.sun.javac.Main" :-(
> 
> A solution can be for Cocoon to use one of the compilers it's shipped 
> with. Don't know if it's feasible, though.

Hmmm, writing our own javac task that extends the ant-shipped javac and 
uses eclipse JDT shouldn't be hard at all.

> <snip/>
> 
>> I think this is YAGNI. 
> 
> 
> You like this acronym, eh ? ;-)

Yes, I love it :)

>> I say: let's start incrementally: we build one well-done 
>> build.sh-driven distro and see what is the user reaction. *then* move 
>> from there.
>>
>> What do you think?
> 
> If we can solve the JAVA_HOME issue, then +0.

What do others think?

Stefano.



Mime
View raw message