forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Re: Use of src/resources/*
Date Tue, 24 Sep 2002 02:31:28 GMT
On Mon, Sep 23, 2002 at 10:51:39PM +0200, Marc Portier wrote:
> in favour:
> - it is as easy as hell,
> - it spreads the forrest-line of thinking even more...
> 
> caveats:
> - it makes this layout part of our 'public interface', people 
> will start depend on it (but some probably already do)
> - imposes structure on project files (people might resent)
> 
> the go-between could be in more properties (or config files)
> ${project.conf-dir}
> ${project.img-dir}
> ${project.schema-dir}
> ${project.xsl-dir}
> after all, this is an ant thing, right?

Currently forrest.build.xml does take this approach, where every
directory type is named by a property. I'm beginning to think it's a
mistake though. Simple example: if a user wants the structure:

/xdocs
/xdocs/images

A simplistic mapping to properties would give:

${project.xdocs-dir} = /xdocs
${project.images-dir} = /xdocs/images

But that's no good, because the images/ dir would be copied as part of
xdocs.

Also, rearranging the directories can break user's assumptions. Say that
/xdocs/index.xml has an image link, <img href="images/hello.gif"/>. If we
go and copy ${project.images-dir} to build/tmp/context/resources/images,
that's going to stuff up the user's links.

Yet another reason is that it limits the types of resources the user can
have. Imagine I write a DVSLTransformer, and want to store DVSL files in
src/documentation/resources/dvsl. It can't be done with the properties
approach.


The only workable alternative I can see is to take a hands-off approach.
Say, "we don't care what your dir structure is. Just point us to your
sitemap and a base directory, and we'll build a webapp from it". Not sure
how it would work though..

Just RTs.


--Jeff

> together with them defaulting to the dirs you mentioned...
> 

Mime
View raw message