forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: using a project local-catalog (Was: copy-conf happens too late in build)
Date Wed, 20 Nov 2002 06:34:08 GMT
On Wed, Nov 20, 2002 at 10:39:47AM +1100, David Crossley wrote:
> Jeff Turner wrote:
> > David Crossley wrote:
> > > I think that i have found a little glitch in the build.
> > > 
> > > The target "copy-conf" copies the cocoon.xconf from the
> > > project src/documentation/conf directory. However it does
> > > this too late in the build process.
> > > 
> > > The validation targets need it to be in place before they
> > > are called. The project can define their local OASIS catalog
> > > in their cocoon.xconf (see validation.xml, search for
> > > "local-catalog" and see the Warning notes).
> > 
> > It doesn't look like local catalog files are used at all.  If a file
> > 'catalog' is defined, it overwrites the default 'catalog', but
> > overwriting is not the same as augmenting..
> I think that i have not been clear enough, and i got
> something wrong above (hence change of email Subject).
> For now, forget the "copy-conf too early" stuff.
> It *may* be a furphy.
> However, there are still issues.
> I already do have my project's additional catalog being
> used as well as the default Forrest catalog. I modified
> Jeff's warnings in validation.xml because they were not
> true. I have shown a workaround in validation.xml
> to add my local-catalog and followed the instructions
> in your-project.xml to add your example Download DTD.
> Everything works for me and i see the HTML page
> rendered properly by Cocoon.

Good stuff.. I didn't know about 'local-files' when I tried it.

> However, validate-xdocs does not work and i do need to set
> forrest.validate.xdocs=false
> I know what the issue is. We have two separate concerns
> which are identified by the two separate warnings in
> validation.xml document.
> ----
> 1) Get Cocoon to use our "local-catalog" during the "docs"
> target, for which we need our local cocoon.xconf instead
> of using the one supplied by default from 'forrest'.

Yes, the possibility of providing one's own cocoon.xconf is (and always
should be) present.

However there's no need to *require* a user to define their own
cocoon.xconf just to use a local catalog.

We could just have a token in the standard cocoon.xconf:

<parameter name="local-catalog" value="@project.catalog@"/>

Just like we currently have a token in cocoon.xconf to determine the


The token value would be set from a 'project.catalog' property, which would be
also used in Ant validation (see below).

> We also need to be able to set the <entity-resolver>
> verbosity parameter in our cocoon.xconf to be able to
> debug entity resolution. (Also tweak other components.)

Then in the default cocoon.xconf we could have:

<parameter name="verbosity" value="@forrest.catalog-verbosity@"/>

And of course, if more flexibility is required, users can always define
their own cocoon.xconf.

> ----
> 2) Ant cannot yet utilise the local catalog during the
> "validate-*" targets.

Yes it can...

> I wonder if the new work happening on xml-commons-dev will help.
> Norm is making the new release of resolver-1.1, and Craeg and
> Stefan are adding that to Ant.

The Ant 1.6 currently used in Forrest has non-standard support for
multiple external catalogs, so is technically capable of using both
Forrest's and the project's catalogs.  Craeg wrote the Ant patch, and
(thanks Stefan!) it seems it has now been applied to Ant's CVS.

Specifically, here is the relevant part of

  <xmlvalidate failonerror="${forrest.validate.xdocs.failonerror}" lenient="no" warn="yes">
      <catalogfiles dir="${project.schema-dir}">
        <include name="catalog*"/>
      <catalogfiles dir="${forrest.home}/context/resources/schema">
        <include name="catalog" />

If we define a 'project.catalog' property, then it could be used in a
<catalogfiles> block, so the project catalog is used in validation.


View raw message