Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Date: 3 Nov 2003 23:49:08 -0000
Message-ID: <20031103234908.8084.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: dev@ant.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 24366]  -
    Project tag basedir attribute should be relative to ${user.dir} (the
 user's current working directory)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24366>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24366

Project tag basedir attribute should be relative to ${user.dir} (the user's current working directory)

stevel@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


------- Additional Comments From stevel@apache.org  2003-11-03 23:49 -------
I think I see what you are trying to do -make a reusable build file that you can
invoke from anywhere. If that is what you want, you are going to have to prefix
all your paths, or look at (2) below.

Now, here is why the current policy generally makes sense.

1. using <ant> to invoke an existing project in a subdir; you dont want it to
work on the parent dir, but on its sub directory -without editing the build file
at all.

2. using <ant> for reusable code, just set the dir attr on the task and you can
direct it anywhere. 

3. ant -f  will find a build file up the tree. This is useful if you are deep in
the source tree; ant -f build.xml will find the containing build file and exec
it from its base dir.

4. IDE invocation - the current dir is often where the IDE started, not where
the project.

Marking as Wontfix as (a) I dont believe the arguments make sense apart from one
specialised case, and (b) I dont want to break every single build file on the
planet. 

On the issue of ant being incompatible with shell scripts, well, ant is not a
scripting language. It is a means of declaring what needs to be done to build a
software project. The more you stray from its core functionality, the more its
design decisions make less sense. But by and large, they have some rationality
behind them, apart from the odd exception.

One thing that may make sense would be a new way of invoking build files, one
that sets the base dir to the current dir. That would just be another command
line option and would break nothing. Please, feel free to implement this if you
think your needs are broad enough to merit it.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org