On Thu, 18 Jul 2002 10:43, Berin Loritsch wrote:
> > They wont both work as they use different DTDs. Besides in 6
> > months I am
> > willing to bet no one is going to be maintaining them anyways.
>
> That's the whole problem.  Why did you adopt a new DTD?  Adjust your
> anakia templates to use the current DTD or apply an XSLT stylesheet
> to convert the current DTD to the anakia one.

Gee. Could it be because for about a year I have been begging someone, anyone 
to fix our documentation. I keep getting promises of, "I'll do it this 
weekend", "I'll do it today" yada yada yada. And guess what - thats right 
NOBODY did anything. How many times have I been told that it is going to get 
easier real soon now? (lots) How many times has it turned out to be true? 
(none so far).

Even worse, it has held up building/releasing distributions several times. 
Some of our distributions even had like 13 meg of cocoon and 1 meg of actual 
project. Add into the mix such wonderful features as;
* taking ages to build simple site (is it below 3 minutes yet?)
* spammy output that makes it impossible to read build script
* massive distribution of unreleased cocoon builds
* confusing setup (.uris vs sitebook vs xml pages vs xsl pages)
* baroque setup and hacks seem regular (ie replace hacks that Paul did for 
URIs or that stupid .uris files)
...

Even when it was such an utterly crappy system I was happy to use it if 
someone else maintained it. I was very happy when Nicola said he was going to 
integrate it. The first thing he did? He updated one project, broke about 23 
others and then stopped doing anything. Not to mention that he also broke 
builds aswell due to moves of jars.

So is this the kind of thing you find acceptable?

> > Can't cocoon be improved so that it is more usable and does
> > not require the
> > same crap to be repeated in each project?
>
> Yes it can.
>
> Exactly what crapola are you wanting to see go away?

The repetition of all the dtds. The book.xml (should move to project.xml which 
is a little clearer). The .uris files and any duplicated graphics (like 
changelog graphics). The numerous duplicated crap in stylesheet directories.

It would be nice to be able to do something like

<property name="style" value="tigris-style.jar"/>

<taskdef name="cocoon" class="...">
  <fileset dir="${xml-site.dir}/lib"/>
</taskdef>

<cocoon destDir="dist/docs" srcDir="src/xdocs">
  <pipeline name="default">
    <include name="**/*.xml"/>
    <exclude name="**/changes.xml"/>
  </pipeline>
  <pipeline name="changes">
    <include name="**/changes.xml"/>
  </pipeline>
</cocoon>

the tigris-style.jar would contain all the stylesheets, common images, 
sitemap/pipeline definitions.

The cocoon jars would come from a release (preferably) or from another 
NON-Avalon CVS that is shared between multiple users and thus can be 
considered stable.

etc.

ie Make it easy to use and it will be used but make it painful and I really 
cant see any good reason to move to it.

-- 
Cheers,

Peter Donald
*------------------------------------------------*
| The student who is never required to do what   |
|  he cannot do never does what he can do.       |
|                       - John Stuart Mill       |
*------------------------------------------------*


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to