On Tue, 21 Aug 2001, Scott Sanders wrote:
> I had always assumed that the user home build.properties was the 'final
> override'.
No, it actually works in the opposite way (as Jason also mentioned).
For example, the build.xml for commons-collections says, in essence:
<property file="${basedir}/build.properties"/>
<property file="${basedir}/../build.properties"/>
<property file="${user.home}/build.properties"/>
The rule Ant follows is "the first definition of a property wins". That
means you can set up all your standard defaults in
"${user.home}/build.properties", but *override* that on a Commons-wide
basis in "${basedir}/../build.properties", and override the Commons-wide
things just for collections in "${basedir}/build.properties". Only when a
property isn't defined in any of these (or on the ant command line) does
it use the property definitions actually in build.xml.
So, the philosophy this is based on is to record all your usual defaults
in your user home directory, and record *exceptions* to those rules at
lower levels.
> I had also always assumed that the local build.properties
> actually sat in CVS and contained the default values.
>
Actually, "build.properties.sample" sits in CVS - if you put a
build.properties in this directory yourself, it's because you need to
customize things for *your* particular environment.
> Craig, if I understand you correctly, you are saying the oppostie? I am
> just trying to clear up my understanding of the process.
>
User home properties are the 'next to last' resort. The real defaults are
actually anything in build.xml itself.
The original design is based on the way that the Ant developers set up
Ant's build.xml environment. I assume that those guys have a few clues
about what makes sense :-).
> Thanks,
> Scott Sanders
>
Craig
> > > > -1 ... the load from ${user.home}/build.properties should go *last*,
> > > > not *first*. You want to be able to set your "usual" properties in
> your
> > > > home directory, but override them for this particular package if
> > > > necessary.
> > >
> > > lib.repo is defined in ~/build.properties
> > >
> > > It has to come before the project/build.properties because
> > > project/build.properties references lib.repo
> > >
> > > If you have another way to do it, then you figure it out so that it
> works
> > > properly.
> > >
> > > -jon
> > >
> > >
> >
> > The philosophy used in all the non-Turbine implementations of build
> > scripts :-) is that you *don't* define everything in the local project's
> > build.properties -- you only code the exceptions. Therefore, you would
> > define lib.repo in your project's file if you *didn't* want to use the
> > standard one in your home directory.
> >
> > See my previous message for a real-life scenario where your proposed way
> > creates an inability to do what *I* as a developer need to do.
> >
> > Craig
> >
> >
> >
>
>
