Thanks, actually your suggestion led me to find that I can use a <url>
resource using a baseResource of ${ant.file.project-name} with a relative
path of "/foo", and this works well. I too had to create a variation that
could load the same resource using a <file> resource, but it wasn't too
hard. I'll probably refactor to use a macrodef or scriptdef, but I think
it's working the way I want.
I still wonder, though, if there's a difference between how <import> is
looking for resources on the default classpath and how <loadproperties> and
<loadresource> work. I'd prefer they were consistent so that I could use
those tasks and have them work the same way <import> does.
Rich
On Fri, Apr 8, 2011 at 10:59 AM, Matt Benson <gudnabr...@gmail.com> wrote:
>
> Rich:
> My approach to this is a little different than yours as I
> import/include resources rather than using Antlibs for my
> compartmentalized build, in a manner similar to Joe Scmetzer's [1].
> This allows me to make use of the ant.file.projectname and
> ant.file.type.projectname properties, which I query, ultimately, in a
> macrodef that uses the file vs. url information exposed therein to
> understand how to obtain a relative resource. For good measure I also
> provide macrodefs to include-relative and import-relative which
> themselves delegate back to the all-important macro that actually
> determines what a relative resource looks like. It might be possible
> for similar properties to be added to Ant for Antlibs, but from what I
> can tell so far it would indeed be a good bit trickier than the
> approach I describe.
>
> HTH,
> Matt
> [1] http://www.exubero.com/asl/
>
> > Thanks,
> > Rich
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
> For additional commands, e-mail: user-h...@ant.apache.org
>
>
