Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E7F1802.20001@anyware-tech.com>
Date: Mon, 24 Mar 2003 15:36:50 +0100
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3b) Gecko/20030210
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [proposal] a new kind of 'dist'
References: <200303241736.29892.niclas@hedhman.org>
 <3E7DC3CD.4090007@apache.org>
 <20030324092537.GD18106@bremen.dvs1.informatik.tu-darmstadt.de>
 <200303241736.29892.niclas@hedhman.org>
 <5.2.0.9.0.20030324074112.00b05d28@leverageweb.com>
 <3E7F1036.8090203@apache.org>
In-Reply-To: <3E7F1036.8090203@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stefano Mazzocchi wrote:

> Geoff Howard wrote:
>
>> At 06:13 AM 3/24/2003, you wrote:
>>
>>> Niclas Hedhman wrote:
>>>
>>>> On Monday 24 March 2003 17:25, Christian Haul wrote:
>>>>
>>>>> This is an open *source* project, and a couple of things are a lot
>>>>> easier to do at compile time rather than at run time.
>>>>
>>>>
>>>>
>>>> Yes, like
>>>> ./configure --prefix=/usr/local/
>>>> make
>>>> make install
>>>> for specifying installation directory, right?
>>>
>>>
>>>
>>> Oh, please, that's not the case. Cocoon is *NOT* an application, 
>>> it's a framework. Our users are developers. They *MUST* be. What's 
>>> the point of having a joe-user-proof installation system to avoid 
>>> them to open up the hood when they *will* have to take the engine 
>>> apart anyway later?
>>>
>>>> Need to think beyond the power-programmer... Even the casual 
>>>> programmer struggles with configure/make systems, and often fails 
>>>> and leaves.
>>>
>>>
>>>
>>> If the casual programmer is not able to do
>>>
>>>  > export JAVA_HOME=/usr/java/
>>>  > ./build.sh webapp
>>>  > ./cocoon.sh servlet
>>>
>>> that it does *US* a favor if he fails and leaves. Open source is not 
>>> about market share, it's about solid communities.
>>
>>
>>
>> Cocoon cuts across a number of different disciplines (java, xml at 
>> least?) and so "casual programmer" means different things.  
>
>
> Very true.
>
>> I am amazed at the number of people on users who claim to know no java.  
>
>
> 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.

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] ;-)

>> - 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.

<snip/>

> I think this is YAGNI. 

You like this acronym, eh ? ;-)

> 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.

Sylvain

[1] http://www.joelonsoftware.com/articles/LeakyAbstractions.

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }