Re: v1.3 -- problems retrieving properties from

[Diane Holt <ho...@yahoo.com>]

--- "Webb, James" <ja...@vignette.com> wrote:
> Are there any known issues in 1.3 or config tricks for 
> retrieving properties from a properties file?
> I have not seen any bugreports or patches for this kind
> of issue.

Not exactly. The properties do get set -- the known issue is that it's
just the log message you get when running -verbose that says it doesn't. I
think it only happens when you build up a property based on the value of
earlier properties, but I haven't tested it to say for certain that's
true. In any case, you can ignore the message, so long as the properties
have the correct value once you're actually executing targets.

(Maybe this should go in the FAQ.)

Diane

=====
(holtdl@yahoo.com)



__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

Re: v1.3 -- problems retrieving properties from

[Conor MacNeill <co...@cognet.com.au>]

From: "Diane Holt" <ho...@yahoo.com>
> --- Nico Seessle <ni...@apache.org> wrote:
> > > (Maybe this should go in the FAQ.)
> > >
> > The better place would be Bugzilla with a little testcase :-) So we can
> > fix that and don't need to describe wrong behaviour...
>
> As I recall, it may not be fixable -- I think it has to do with the order
> in which properties get set. That is, if you have something like:
>
> root.dir=/my/tree
> out.dir=${root.dir}/classes
>
> you will likely get a log message saying that property root.dir isn't
set.
> Conor could probably explain it in more detail.
>

OK, when reading in from a properties file, you can ignore this message :-)

What happens is this:

The properties are read in as a Properties object. They are then read out
with an enumeration and added to Ant's collection of properties. The order
of properties returned by that enumeration is, in general, not the same as
the order of the properties in the file. So, there may effectively be
forward references in the order returned by the enumeration. When this
occurs, Ant will print this message but then resolve the forward reference
within the properties object from the properties file.

In other words, properties in a properties file are more declarative than
those in a build file :-).

Now I agree that the warning there is a problem. The reason I left it in,
however, is that it is generally very difficult to catch use of properties
which are not set. I'll probably get rid of it now.

So, to the original poster, if you ignore the messages, can you check that
the values are actually being set correctly.

Sorry for the confusion.

Conor

Re: v1.3 -- problems retrieving properties from

[Diane Holt <ho...@yahoo.com>]

--- Nico Seessle <ni...@apache.org> wrote:
> > (Maybe this should go in the FAQ.)
> >
> The better place would be Bugzilla with a little testcase :-) So we can
> fix that and don't need to describe wrong behaviour...

As I recall, it may not be fixable -- I think it has to do with the order
in which properties get set. That is, if you have something like:

root.dir=/my/tree
out.dir=${root.dir}/classes

you will likely get a log message saying that property root.dir isn't set.
Conor could probably explain it in more detail.

Diane


=====
(holtdl@yahoo.com)



__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

Re: v1.3 -- problems retrieving properties from

[Nico Seessle <ni...@apache.org>]

----- Original Message -----
From: "Diane Holt" <ho...@yahoo.com>
To: <an...@jakarta.apache.org>
Sent: Wednesday, May 02, 2001 4:09 AM
Subject: Re: v1.3 -- problems retrieving properties from <property
file="SOMEF ILE">


> Not exactly. The properties do get set -- the known issue is that it's
> just the log message you get when running -verbose that says it doesn't. I
> think it only happens when you build up a property based on the value of
> earlier properties, but I haven't tested it to say for certain that's
> true. In any case, you can ignore the message, so long as the properties
> have the correct value once you're actually executing targets.
>
> (Maybe this should go in the FAQ.)
>
The better place would be Bugzilla with a little testcase :-) So we can fix
that and don't need to describe wrong behaviour...

Nico