You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by ho...@apache.org on 2002/04/01 07:41:30 UTC

cvs commit: jakarta-ant/src/main/org/apache/tools/ant/taskdefs Ant.java

holtdl      02/03/31 21:41:30

  Modified:    src/main/org/apache/tools/ant/taskdefs Ant.java
  Log:
  If 'output' is a simple or relative filename, make it relative
  to ${basedir}, not ${user.dir}. (If it's a full-path, it'll go
  to the full-path file.)  (PR 4548)
  
  Revision  Changes    Path
  1.44      +7 -2      jakarta-ant/src/main/org/apache/tools/ant/taskdefs/Ant.java
  
  Index: Ant.java
  ===================================================================
  RCS file: /home/cvs/jakarta-ant/src/main/org/apache/tools/ant/taskdefs/Ant.java,v
  retrieving revision 1.43
  retrieving revision 1.44
  diff -u -r1.43 -r1.44
  --- Ant.java	3 Mar 2002 01:46:20 -0000	1.43
  +++ Ant.java	1 Apr 2002 05:41:30 -0000	1.44
  @@ -104,7 +104,8 @@
       private String target = null;
       
       /** the output */
  -    private String output = null;
  +    private String output  = null;
  +    private String outfile = null;
       
       /** should we inherit properties from the parent ? */
       private boolean inheritAll = true;
  @@ -174,8 +175,12 @@
           }
   
           if (output != null) {
  +            if (dir != null) {
  +                File file = FileUtils.newFileUtils().resolveFile(dir, output);
  +                outfile = file.getAbsolutePath();
  +            }
               try {
  -                PrintStream out = new PrintStream(new FileOutputStream(output));
  +                PrintStream out = new PrintStream(new FileOutputStream(outfile));
                   DefaultLogger logger = new DefaultLogger();
                   logger.setMessageOutputLevel(Project.MSG_INFO);
                   logger.setOutputPrintStream(out);
  
  
  

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/taskdefs Ant.java

Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 3 Apr 2002, Diane Holt <ho...@yahoo.com> wrote:

> Clearly, I agreed with the PR and thought it should go into the dir
> of the build file that's being called, since that way you can at
> least in some way identify which build file the output's coming
> from.

OK, this is what the current version does.

Want to patch the documentation?

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/taskdefs Ant.java

Posted by Diane Holt <ho...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> See the code in execute that immediately preceedes the call to
> initializeProject, it will leave dir as null if inheritAll is false

Rats! -- the one little booger I didn't test for. Sorry about that.
(That's why I'm not QA :)

> But the question remains, where do we want to put the logfile if the
> user has specified a dir attribute.  Into dir or still use the current
> projects basedir?  We are talking about a backwards incompatible
> change anyway, but one that can be called a bugfix for very good
> reasons 8-).

Clearly, I agreed with the PR and thought it should go into the dir of the
build file that's being called, since that way you can at least in some
way identify which build file the output's coming from. Of course, that
doesn't doodley for output from build file's being run from the same
directory, but at least it was something.

Diane

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



__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/taskdefs Ant.java

Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 2 Apr 2002, Diane Holt <ho...@yahoo.com> wrote:

> Hmm... I tested the snot out of it, so I'm surprised to hear that.

To be honest, I didn't actually test it, just ran the code in my head.
If dir is null, you'll get a NullPointerException - I didn't see that
it is extremely unlikely that dir is null, but it is possible.

See the code in execute that immediately preceedes the call to
initializeProject, it will leave dir as null if inheritAll is false
and dir hasn't been specified (to not override the basedir of the new
project).

> I ran it (with my changes) without specifying a dir, and it worked
> fine.

set inheritall to false - I think I'll simply add a JUnit testcase
that demonstrates the failure and fix it after that.

Run this:

<project name="foo" default="bar">
  <target name="foo">
    <echo message="baz"/>
  </target>

  <target name="bar">
    <ant inheritall="false" output="zyzzy.log" target="foo"
         antfile="foo.xml"/>
  </target>
</project>

>> As I'm not sure what you want to do in the presence of a dir
>> attribute, therefore I'm not patching the task right now.
> 
> The previous behaviour was that the output file would be created in
> the current directory rather than in the directory of the build file
> being called (if different from the current directory).

Yes.

But the question remains, where do we want to put the logfile if the
user has specified a dir attribute.  Into dir or still use the current
projects basedir?  We are talking about a backwards incompatible
change anyway, but one that can be called a bugfix for very good
reasons 8-).

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/taskdefs Ant.java

Posted by Diane Holt <ho...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> On 1 Apr 2002, <ho...@apache.org> wrote:
> 
> >   If 'output' is a simple or relative filename, make it relative
> >   to ${basedir}, not ${user.dir}. (If it's a full-path, it'll go
> >   to the full-path file.)  (PR 4548)
> 
> Your patch will not make that happen.

Hmm... I tested the snot out of it, so I'm surprised to hear that.

> What we have now:

When you say "now", do you mean after my change, or before?

> * user has specified a dir attribute -> output is resolved relative to
> dir, not to ${basedir}

Doesn't the specified dir become ${basedir}?

> * user has not specified a dir attribute -> NullPointerException
> (outfile is null in the first line of the try block).

I ran it (with my changes) without specifying a dir, and it worked fine.

> As I'm not sure what you want to do in the presence of a dir
> attribute, therefore I'm not patching the task right now.

The previous behaviour was that the output file would be created in the
current directory rather than in the directory of the build file being
called (if different from the current directory). I *thought* my change
fixed that (I tested it in every conceivable configuration, with a 'dir',
without a 'dir', with -logfile to see if that weirded things out, etc.),
but if I didn't do it right (always a possibility), please feel free to
correct it.

Diane

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



__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://http://taxes.yahoo.com/

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/taskdefs Ant.java

Posted by Stefan Bodewig <bo...@apache.org>.
On 1 Apr 2002, <ho...@apache.org> wrote:

>   If 'output' is a simple or relative filename, make it relative
>   to ${basedir}, not ${user.dir}. (If it's a full-path, it'll go
>   to the full-path file.)  (PR 4548)

Your patch will not make that happen.

What we have now:

* user has specified a dir attribute -> output is resolved relative to
dir, not to ${basedir}

* user has not specified a dir attribute -> NullPointerException
(outfile is null in the first line of the try block).

As I'm not sure what you want to do in the presence of a dir
attribute, therefore I'm not patching the task right now.  The
(untested) patch below would make it

* user has specified a dir attribute -> output is resolved relative to
dir, not to ${basedir}

* user has not specified a dir attribute -> output is resolved
relative to ${basedir}

If you really just want to resolve it relative to ${basedir}, forget
the dir != null case.

Stefan

Index: src/main/org/apache/tools/ant/taskdefs/Ant.java
===================================================================
RCS file: /home/cvs/jakarta-ant/src/main/org/apache/tools/ant/taskdefs/Ant.java,v
retrieving revision 1.44
diff -u -r1.44 Ant.java
--- src/main/org/apache/tools/ant/taskdefs/Ant.java	1 Apr 2002 05:41:30 -0000	1.44
+++ src/main/org/apache/tools/ant/taskdefs/Ant.java	2 Apr 2002 15:13:29 -0000
@@ -105,7 +105,6 @@
     
     /** the output */
     private String output  = null;
-    private String outfile = null;
     
     /** should we inherit properties from the parent ? */
     private boolean inheritAll = true;
@@ -175,10 +174,13 @@
         }
 
         if (output != null) {
+            File outfile = null;
             if (dir != null) {
-                File file = FileUtils.newFileUtils().resolveFile(dir, output);
-                outfile = file.getAbsolutePath();
+                outfile = FileUtils.newFileUtils().resolveFile(dir, output);
+            } else {
+                outfile = getProject().resolveFile(output);
             }
+            
             try {
                 PrintStream out = new PrintStream(new FileOutputStream(outfile));
                 DefaultLogger logger = new DefaultLogger();

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>