On Thu, 2002-07-18 at 10:56, Leo Sutic wrote:
> > From: Peter Donald [mailto:[EMAIL PROTECTED]]
> >
> > 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)
> > ...
>
> I think these are the most important reasons not to use Cocoon.
yup.
> My first contact with our doc-building environment was a definite
> turn-off. A lot of copying and filtering and incomprehensibilities.
yup. Thing is, the filtering hasn't actually got to do with cocoon!
> Just like Peter I think that a <cocoon/> task in Ant would be the
> optimal. Actually, I can not think of anything else that would
> be usable in the long run if we go for Cocoon.
uhuh.
> Just a simple thought on what can be done to make it more viable:
>
> Factor out all cocoon related ant "code" to a separate build file
> that is kept in the excalibur or Avalon root. cocoon-docs.xml.
>
> Then use the <ant/> command with parameters to call a target in
> this file.
>
> The major thing leading to unmaintainability is that *all* code
> required to run Cocoon is duplicated in *every* project.
>
> I'd like to be able to do:
>
> <ant antfile="../docs.xml"/>
Been working on doing exactly that. If you look at xcommander in avalon
apps, it's html-docs targets does
<ant antfile="../build.xml" target="module:html-docs"/>
where the html-docs target looks for the of the system to use, then does
<antcall target="cocoon:html-docs"/>
when I get all this working well, we could move the ../build.xml into
avalon.
> + Some of our distributions even had like 13 meg of cocoon and
> 1 meg of actual project.
>
> Major one here. Yes, Cocoon should be stripped down to essentials.
> The Cocoon distro is a massive do-everything package (it even includes
> HypersonicSQL, which isn't vital at all to Cocoon). What is the most
> minimal Cocoon package possible?
we've got an 1.5mb jar now, not including xerces or xalan.
> + taking ages to build simple site (is it below 3 minutes yet?)
>
> Cocoon is fast on my fast machine. But that's not really a solution
> is it?
the new one is fast enough, if you ask me. It takes about 3 times longer
than anakia.
> + spammy output that makes it impossible to read build script
>
> Yep. Can we limit the log level to WARN or ERROR? There are many
> places in Cocoon where, for example, the lookup() method is used
> instead of the hasComponent() method. Thus you get a WARN and a
> huge stack trace even though nothing is wrong. But this is something
> that can be fixed.
I suspect Berin will do so soon =)
>
> + massive distribution of unreleased cocoon builds
>
> Minimal distro, as described above.
1.5mb is still a lot, but I can live with it
> + confusing setup (.uris vs sitebook vs xml pages vs xsl pages)
>
> I'm sure we can do something about that.
I don't like the .uris. I think the setup should be
- book.xml
- documents using document-v10.dtd
- non-documents inside same directory
- optinal property file with a use.skin={bla} setup
> The above is, as you probably all think, a load of handwaving and
> not very much of actual work by me.
=)
> But, Peter, Berin, if this could be made to work, would it be
> acceptable for both of you?
the important part is not getting it to work but doing the maintainance
once it works, I think.
cheers,
- Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
