Geoff Howard wrote:
<snip/>
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.
They must be xml/xslt programmers which _may_ mean some combination of: - they don't usually use the command line for anything
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.
Ah. I must screw this process up by supplying a non-default location because I hate having java installed under Program Files for a number of reasons.
- they have never built any software from source, which means if our build fails for them for any reason, they will assume that Cocoon doesn't work, or is too complicated for them. some may turn away if "build" seems too mysterious to them
true
- a few other points I can't remember now along similar lines.
I'm not saying I'm against this idea at all - in fact it has some great benefits. I'm just trying to clarify the psychological barriers I see that need to be taken into account in *how* it's done.
and this is valuable input.
Stefano's point about hiding the build behind configuring and installing is a good one, as long as the build time stays relatively low. 10 minutes _max_ for a full build (which most people won't do) would keep things reasonable IMHO.
I think we meet that time-period on almost any modern machine. Even on my old laptop that was more or less so.
I think I like the jnlp option, if it's not required (was jnlp even available with jdk1.3?) and even though I have little GUI skills and no experience with jnlp, I'd be willing to help work on that.
I think this is YAGNI.
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?
Stefano.
I'd go for that, but there are still some strong opinions out there to the contrary. Would it help the psychological barrier to have a user friendly "Where is the binary" document/paragraph available and hard to miss that explains why we think even non programmers can and should build this from source?
BTW, isn't jnlp installed by default with 1.4?
Geoff (who is not too proud to admit he had to look up YAGNI)
