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 }
