Kyle Adams [[EMAIL PROTECTED]] wrote:
> build.properties
> ===
>
> lib.home = /usr/java/libraries
> foo.path = ${lib.home}/foo.jar
> bar.path = ${lib.home/bar1.jar:${lib.home}/bar2.jar
>
> build.xml
> ==
>
>
>
>
>
>
>
>
> > And I can find no way to tell Ant to us
First off, thanks to Holly for the good advice. I'll be looking at a better
"default" location for my properties files, as suggested.
Hmm... I don't know of any way to "define" something in a properties file
as a particular object (ie, a path). Right now property files are (to the
best of my
file.
I could store the information as property strings, and then define the
elements in each build file that needs to use them, but that is what
I am trying to avoid.
Regards,
John McGrath
-Original Message-
From: Kyle Adams [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 09, 20
--- Kyle Adams <[EMAIL PROTECTED]> wrote:
> As I stated before, we're dealing with a situation in which the dev root
> may vary. The nastiest variation is that many of our developer's
> machines have multiple drives, so their root might be anything from c:
> to x:, though d: is the recommended, a
As I stated before, we're dealing with a situation in which the dev root may vary.
The nastiest variation is that many of our developer's machines have multiple drives,
so their root might be anything from c: to x:, though d: is the recommended, and
anyone (so far) that isn't using d: is using
--- Kyle Adams <[EMAIL PROTECTED]> wrote:
> The problem I ran into with this is that the root, or the drive that
> development-related stuff was stored on, changed depending on the user.
> For some it was d:, for others c:, and for others still, plain ol' *nix
> root ('/'). So the location of th
You could - this is also a viable solution. In my case, I wanted to minimize the
variables that had to be passed in from the command line. That way means less typing
if the developer wants to bypass the wrapper script (for example, to turn on verbose
logging).
There are disadvantages to each
Couldnt you just specify the properties file location with a
ant -DANT_PROPERTIES_LOCATION=$ANT_PROPERTIES_LOCATION
And then using the tag inside like this
The users would be responsible for specifying the proper path to the properties file,
or like in my example this could be a system var
The problem I ran into with this is that the root, or the drive that
development-related stuff was stored on, changed depending on the user. For some it
was d:, for others c:, and for others still, plain ol' *nix root ('/'). So the
location of their source tree changed. Which mean that Ant c
I don't know that I'd recommend having a requirement that a file used in
the production of the build be placed in a user's home directory -- you
can allow for the option of users having a properties file in their home
directory in order to set the value of customizable properties, but you
shouldn'
Sounds to me like your problem is you need a standard place to put your properties
file. That way, no matter what platform or system the file is on, Ant will always be
able to find it, and use it to locate various libraries.
If this is the case, then you might be able to make use of the ${user
I have been having a tough time setting up Ant files the way I want, and am
hoping someone can suggest an approach that will work.
I have a number of projects for which I am creating Ant build files, and
each of these projects use some number of third-party libraries. I have to
be able to build
12 matches
Mail list logo
