forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: [wip][update] build refactoring - first use possible
Date Fri, 23 Aug 2002 15:30:59 GMT
On Fri, Aug 23, 2002 at 01:35:32PM +0200, Marc Portier wrote:
> Hi all,
> been fleshing out more in the new build system

Cool :)

> there is something working now:
> ./ -buildfile clean docs
> will now do the equivalent of what the (old) build.xml does

I'm just about to head off to bed, but :


/old/home/jeff/homeoverflow/apache/xml/xml-forrest/ /old/home/jeff/homeoverflow/apache/xml/xml-forrest/src/resources/fresh-site
not found.

Perhaps you didn't check in that directory?

> Except:
> - it will do it based on the better separation of concerns we
> have been discussing (could be a bit slower, please feedback)
> - it will no longer require the 'clean' cause this nukes the
> cocoon cache internally before re-generation
> However:
> when using this new way of working I get loads of
> anyone that has a clue?

I think it means an attribute value is bad. I got them in another project when
I had:

<fo:table-column column-width="something_bad"/>

No idea otherwise :/

> Question:
> we still have the not-liked filtering in our build
> I saw the maven guys used it for configuring more then the skin
> Any opinions on being able to configure more?

Yes please.. I need *lots* of configurability. Eg, currently the sitemap
hardcodes relative paths, like 'content/xdocs' and 'resources/images'. I'd
really like those to be configurable, so that I can override them to the Maven
defaults (by default, /xdocs and /xdocs/images respectively).

Actually, the cleanest way to handle dynamic, property-driven Maven situation
is probably to create a sitemap on the fly, when the plugin is first invoked.


> regards,
> -marc=

View raw message