I second this ..

I wrote a Property2 file that handles this because we need to use it in
order to have only a single general build.xml file to build / package an
arbitrary number of projects.  

Here is an example of how we use it.  The label of a project jar is
specified in a property file such as

-------- ../proj1/version.prop
proj1.label=proj1-2.0.5_DEV
--------

We invoke then invoke ant to build this project by

--------
ant -Dproject.name=proj1
--------

And our build.xml file uses the passed in property to get the correct label

-------- ../build.xml
   <property2 name="jarFile" value="${${project.name}.label}.jar" />
--------

I have included my version of the Property.java taskdef.  I only had to
modify / add ~5 lines of code to implement this.

Thanks.

Pete


-----Original Message-----
From: Rob van Oostrum [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 27, 2001 11:47 AM
To: [EMAIL PROTECTED]
Subject: Re: nested property references


I have a few comments:

- I agree that it is possible that you can work around not having nested
property suppport. But I do consider it a workaround. Giving me a
workaround IMHO does not constitute an argument why the feature itself
is not needed.
- I think that for all practical purposes Ant should either support
nested property references, or it *shouldn't* support setting them (as
in using a property reference in setting the name of a property). The
latter currently works, but it's a useless feature, since you'll never
be able to reference it using the property reference in the property
name. Ant should either do it right, or not at all.

So I think it's just a much more elegant way of setting things up. If
not for any immediate need, I would like to see it in there for the sake
of implementing property references properly. We can go back and forth
with examples of what I'd like to use the functionality for, and how we
can bend over backwards to (mis-) use other functionality, but as I
stated previously, I think this is only a workaround. More than new
functionality, it's just something that IMHO should have been supported
from the start. I know writing recursive code gets really complex really
fast. But there must be enough people in the dev community that are able
to fork this out without breaking a sweat. If someone points me in the
right direction (where are property refs implemented at the moment? ...)
I'll do the coding myself.

Also: a point about references to non-existing properties. I think those
should always generate errors (which they don't, it just causes the
property reference to be used unresolved, which looks very ugly to me).


cheers
Rob


Stefan Bodewig wrote:

> Dave Knox <[EMAIL PROTECTED]> wrote:
>
> > archives.base.dir=archives
> > archives.ow32jdk12.dir=${archives.base.dir}/ow32jdk12
> > archives.ow32jdk13.dir=${archives.base.dir}/ow32jdk13
> > archives.o2kjdk13.dir=${archives.base.dir}/o2kjdk13
>
> You can do this in the build file as well, what JD and Rob have been
> asking for would be something like ${archives.${module}.dir} to
> dynamically swith between the three values you define above.
>
> Stefan

Property2.java

Reply via email to