Mailing-List: contact cocoon-docs-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-docs@xml.apache.org
Date: Mon, 30 Jun 2003 23:21:08 +1000
From: Jeff Turner <jefft@apache.org>
To: cocoon-docs@xml.apache.org
Cc: forrest-dev@xml.apache.org
Subject: Back to home-grown docs? (Re: [RT] New Target: sub-sitemap)
Message-ID: <20030630132108.GA1217@expresso.localdomain>
Mail-Followup-To: cocoon-docs@xml.apache.org, forrest-dev@xml.apache.org
References: <LKENJPKDAIKAPKHEOCMMGECOEBAA.cziegeler@s-und-n.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <LKENJPKDAIKAPKHEOCMMGECOEBAA.cziegeler@s-und-n.de>
User-Agent: Mutt/1.5.4i

On Fri, Jun 27, 2003 at 10:17:35AM +0200, Carsten Ziegeler wrote:
> I was just wondering if it would be possible to make a new
> target for forrest that creates only a subsitemap for cocoon
> instead of a full blown webapp?
> 
> If you use a defined Cocoon version where you put this subsitemap
> into, I think, technically there should only be a few problems:
> - additional jars (no problem, could be put into ${target}/WEB-INF/lib
> - additional config (no real problem, the xpatch tool could patch
>   everything (cocoon.xconf, web.xml, sitemap etc.)
> - links and references - this could be the hardest part, I don't know
>   If everything (stylesheets, images, documents) is linked and referenced
>   relative, moving it into a subdirectory (subsitemap) should be
>   no problem. If there are references to the root of the webapp
>   they have to be changed.

Only real problem is that we rely on cocoon:// URLs in quite a few
places.  This was necessary because cocoon: URLs are resolved relative to
their original caller.  So if cocoon:/subdir/A calls cocoon://B, who
calls cocoon:/C, then it's as if A called cocoon:/subdir/C.

We could work around this by adding a {root} sitemap variable.

> What do you think about the idea? I think this is a common use-case,
> because often you have a (cocoon) webapp and simply want to put
> some (dynamially generated) content into it. For example, the cocoon
> demo could use this for it's own documentation as well.

Off in RT mode a bit..

Every time I upgrade Forrest's jars, I think that Forrest should really
just be a Cocoon block.  Despite its 20mb, there really isn't that much
_content_ in Forrest.  A sitemap, some DTDs, a couple of skins, and an
Ant-driven build process.

That the 'core' of Forrest is so small leads me to wonder if Cocoon
shouldn't just include what it needs of Forrest internally.  That would
be:

The forrest-css skin:  128k
The v12 or v20a DTD :  31k
A bunch of sitemaps :  124k
Image resources     :  20k
Stylesheet resources:  131k
resolver.jar (ant)  :  68k
                       -----
                       502k

Most Forrest developers are also Cocoon developers, so I suspect the cost
of keeping these in synch is lower than the cost to Cocoon developers of
having to deal with Forrest as a separate entity.

The result would be that Cocoon eliminates a dependency, and Forrest
gains a bunch of indirect contributors, as improvements to the Cocoon doc
system get fed back into Forrest.  Plus (and this is the bit that appeals
to me) any Cocoon breakage that affects Forrest will be Cocoon's problem
before it becomes Forrest's ;)

Practically, this amounts to:

1) In Cocoon's existing src/documentation/* doc system, synchronize
   stylesheets, DTDs and images with Forrest's.
2) If everything works, call a vote on cocoon-docs to remove the Forrest
   Ant targets, and use the built-in system.

What do people think?  


--Jeff

> Carsten 
> 
> Carsten Ziegeler 
> Open Source Group, S&N AG
> http://radio.weblogs.com/0107211/