Le 13 déc. 2011 à 02:16, Mitch Gitman a écrit :
> I'm using IvyDE 2.1.0. I'm defining Ivy settings on a per-Eclipse-project
> basis, and in doing so, I'm filling in the "Property files:" field with a
> sequence of comma-separated properties file paths. I'd been expecting that
> the ordering of the properties files would have significance and that the
> definition of a property in an earlier-listed file (one to the left in the
> list) would trump a definition in a later-listed file.
>
> So in an earlier-listed file I would define:
> branch=1.3
> buildnumber=8
>
> And then in a later-listed file I would define:
> buildnumber=0
> revision=${branch}.${buildnumber}-SNAPSHOT
>
> What I'm finding is that ${branch} gets resolved as expected, but
> ${buildnumber} gets resolved to 0, even though 8 was there first in the
> other file. I have:
> revision=1.3.0-SNAPSHOT
>
> I want:
> revision=1.3.8-SNAPSHOT
>
> I'm fine with forcing users to define branch, but I'm not fine with forcing
> users to define buildnumber.
>
> The behavior I'm seeing indicates that I can't define default values for
> IvyDE-specific properties.
>
> What am I missing here? Just as an experiment, I might try defining the
> default value for buildnumber (0) in a third properties file that appears
> in between the other two in the list. Even if that works, that's clearly a
> house-of-cards workaround.
Properties are effectively mutable. This was not a volunteer design but it is
how it works today.
Maybe we can change that. Or add an option to make them immutable.
Nicolas
