Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/junit JUnitReportTest.java

[Stephane Bailliez]

Alexey Solofnenko wrote:
We do not support 1.1 any more.
 

Yes, but at that time we were. :)
toURL does not properly escape illegal characters (see javadoc) so you 
end up kind of like my horrible current hack.
I just checked jaxp implementation, the current implementation in the 
main branch (jaxp 1.3) for parse(File) is still wrong as well AFAIK, it 
is different between from the one in the tck-jaxp-1_2_0 branch which 
does escape. mmm...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/junit JUnitReportTest.java

[Alexey Solofnenko]

We do not support 1.1 any more.

- Alexey.

On 5/13/05, Stephane Bailliez <[EMAIL PROTECTED]> wrote:
> 
> Alexey Solofnenko wrote:
> 
> >Another, question - why not to use File.toURL() method instead?
> >
> >
> JDK 1.2+ method. (yeah sounds like it was last century :)
> 
> 


-- 
Alexey N. Solofnenko trelony at gmail.com 
home: http://trelony.cjb.net/
Pleasant Hill, CA (GMT-8 hours usually)

Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/junit JUnitReportTest.java

[Stephane Bailliez]

Alexey Solofnenko wrote:
Another, question - why not to use File.toURL() method instead?
 

JDK 1.2+ method. (yeah sounds like it was last century :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant WHATSNEW

[stevel]

stevel  2005/05/13 15:12:29

  Modified:.WHATSNEW
  Log:
  more changes, plus some corrections to existing reports.
  
  Revision  ChangesPath
  1.821 +15 -5 ant/WHATSNEW
  
  Index: WHATSNEW
  ===
  RCS file: /home/cvs/ant/WHATSNEW,v
  retrieving revision 1.820
  retrieving revision 1.821
  diff -u -r1.820 -r1.821
  --- WHATSNEW  13 May 2005 08:09:22 -  1.820
  +++ WHATSNEW  13 May 2005 22:12:29 -  1.821
  @@ -74,7 +74,7 @@
 did not always do so.
 
   *  failed to retrieve a file when the path towards the file contained
  -  an element starting with . . Bugzilla report 33770
  +  an element starting with . Bugzilla report 33770
 
   * " always compiles on Java1.5" bugzilla report=33862. Fixed default
 stub version to always be "compat", even on Java1.5+. 
  @@ -93,7 +93,10 @@
   * Targets with identical name work in imported project. Bugzilla Report 
34566.
   
   * DemuxOutputStream now uses a WeakHashMap to store the thread-stream 
mapping,
  -  to avoid holding on to thread references after they terminate. 
  +  to avoid holding on to thread references after they terminate.
  +
  +*  and  create a new parser for every file in a
  +  fileset, and so validate multiple files properly. Bugzilla Report 32791
   
   Other changes:
   --
  @@ -182,14 +185,21 @@
 negate attribute to select lines -not- containing specified text.
 Bugzilla Report 34374.
   
  -*  condition adds "nt" as a family which can be tested. This is
  +*  condition adds "winnt" as a family which can be tested. This is
 all windows platforms other than the Win9x line, and windows CE.  
   
  -*  (and hence, ) have an OsFamily attribute, which can restrict
  -  execution to a single OS family.
  +*  (and hence,  and any other derived classes) have an OsFamily
  +  attribute, which can restrict execution to a single OS family.
   
   * added "backtrace" attribute to macrodef. Bugzilla report 27219.
   
  +* Ant main provides some diagnostics if it ever sees a -cp or -lib option,
  +  as this is indicative of a script mismatch. Bugzilla report 34860
  +
  +*  prints a special message if supplied an empty XML File. This
  +  can be caused by the test JVM exiting during a test, either via a 
System.exit()
  +  call or a JVM crash.
  +
   Changes from Ant 1.6.3 to current Ant 1.6 CVS version
   =
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/junit JUnitReportTest.java

[Alexey Solofnenko]

Another, question - why not to use File.toURL() method instead?

- Alexey.

On 5/13/05, Stephane Bailliez <[EMAIL PROTECTED]> wrote:
> 
> [EMAIL PROTECTED] wrote:
> [...]
> 
> - //XXX there seems to be a bug in xerces 1.3.0 that doesn't like file 
> object
> - // will investigate later. It does not use the given directory but
> - // the vm dir instead ? Works fine with crimson.
> - Document testsuiteDoc
> - = builder.parse("file:///" + files[i].getAbsolutePath());
> 
> Did u remove the comment on purpose ? A lot of water has been flowing
> since I wrote this so I guess it has been fixed but...
> 
> 
> 


-- 
Alexey N. Solofnenko trelony at gmail.com 
home: http://trelony.cjb.net/
Pleasant Hill, CA (GMT-8 hours usually)

Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/junit JUnitReportTest.java

[Stephane Bailliez]

[EMAIL PROTECTED] wrote:
[...]
 -//XXX there seems to be a bug in xerces 1.3.0 that doesn't 
like file object
 -// will investigate later. It does not use the given 
directory but
 -// the vm dir instead ? Works fine with crimson.
 -Document testsuiteDoc
 -= builder.parse("file:///" + files[i].getAbsolutePath());
Did u remove the comment on purpose ? A lot of water has been flowing 
since I wrote this so I guess it has been fixed but...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34860] - Startupscript must not add empty $CLASSPATH to evaluated command

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34860


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Target Milestone|--- |1.7




--- Additional Comments From [EMAIL PROTECTED]  2005-05-14 00:02 ---
FYI, We've just patched ant main to give a special error message when -lib or
-cp get that far down, warning people that they have a probable version mismatch
between ant and the scripts. So the next time someone encounters this problem,
it will be easier to resolve. Your suffering was not completely in vain.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant Main.java

[stevel]

stevel  2005/05/13 14:57:23

  Modified:src/main/org/apache/tools/ant Main.java
  Log:
  added a special case that detects -cp and -lib calls in Main, and tells the 
caller that they have a probable version mismatch.
  
  Revision  ChangesPath
  1.118 +13 -21ant/src/main/org/apache/tools/ant/Main.java
  
  Index: Main.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/Main.java,v
  retrieving revision 1.117
  retrieving revision 1.118
  diff -u -r1.117 -r1.118
  --- Main.java 26 Feb 2005 21:16:58 -  1.117
  +++ Main.java 13 May 2005 21:57:23 -  1.118
  @@ -29,6 +29,7 @@
   import org.apache.tools.ant.input.DefaultInputHandler;
   import org.apache.tools.ant.input.InputHandler;
   import org.apache.tools.ant.launch.AntMain;
  +import org.apache.tools.ant.util.FileUtils;
   
   
   /**
  @@ -212,20 +213,8 @@
*/
   private static void handleLogfile() {
   if (isLogFileUsed) {
  -if (out != null) {
  -try {
  -out.close();
  -} catch (final Exception e) {
  -//ignore
  -}
  -}
  -if (err != null) {
  -try {
  -err.close();
  -} catch (final Exception e) {
  -//ignore
  -}
  -}
  +FileUtils.close(out);
  +FileUtils.close(err);
   }
   }
   
  @@ -424,6 +413,15 @@
   throw new BuildException(
   "Niceness value is out of the range 1-10");
   }
  +} else if (arg.equals("-cp") || arg.equals("-lib")) {
  +//catch script/ant mismatch with a meaningful message
  +//we could ignore it, but there are likely to be other
  +//version problems, so we stamp down on the configuration now
  +String msg = "Ant's Main method is being handed "
  ++ "an option "+arg+" that is only for the launcher 
class."
  ++ "\nThis can be caused by a version mismatch 
between "
  ++ "the ant script/.bat file and Ant itself.";
  +throw new BuildException(msg);
   } else if (arg.startsWith("-")) {
   // we don't have any more args to recognize!
   String msg = "Unknown argument: " + arg;
  @@ -476,13 +474,7 @@
   System.out.println("Could not load property file "
  + filename + ": " + e.getMessage());
   } finally {
  -if (fis != null) {
  -try {
  -fis.close();
  -} catch (IOException e) {
  -// ignore
  -}
  -}
  +FileUtils.close(fis);
   }
   
   // ensure that -D properties take precedence
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/junit JUnitReportTest.java

[stevel]

stevel  2005/05/13 14:54:14

  Modified:src/testcases/org/apache/tools/ant/taskdefs/optional/junit
JUnitReportTest.java
  Log:
  and of course the date change.
  
  Revision  ChangesPath
  1.9   +1 -1  
ant/src/testcases/org/apache/tools/ant/taskdefs/optional/junit/JUnitReportTest.java
  
  Index: JUnitReportTest.java
  ===
  RCS file: 
/home/cvs/ant/src/testcases/org/apache/tools/ant/taskdefs/optional/junit/JUnitReportTest.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- JUnitReportTest.java  13 May 2005 21:42:23 -  1.8
  +++ JUnitReportTest.java  13 May 2005 21:54:14 -  1.9
  @@ -1,5 +1,5 @@
   /*
  - * Copyright  2002,2004 The Apache Software Foundation
  + * Copyright  2002,2005 The Apache Software Foundation
*
*  Licensed under the Apache License, Version 2.0 (the "License");
*  you may not use this file except in compliance with the License.
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/junit JUnitReportTest.java

[stevel]

stevel  2005/05/13 14:42:23

  Modified:src/etc/testcases/taskdefs/optional junitreport.xml
   src/main/org/apache/tools/ant/taskdefs/optional/junit
XMLResultAggregator.java
   src/testcases/org/apache/tools/ant/taskdefs/optional/junit
JUnitReportTest.java
  Added:   src/etc/testcases/taskdefs/optional/junitreport
INCOMPLETE-sampleproject.incomplete.xml
NAMESPACE-sampleproject.namespace.xml
WRONGELEMENT-sampleproject.wrongelement.xml
ZEROBYTES-sampleproject.package.xml
  Log:
  tests for junitreport handling various forms of bad data, plus explicit 
handling of zero-byte files with a different error message..
  
  Revision  ChangesPath
  1.1  
ant/src/etc/testcases/taskdefs/optional/junitreport/INCOMPLETE-sampleproject.incomplete.xml
  
  Index: INCOMPLETE-sampleproject.incomplete.xml
  ===
  
  








  
  
  
  1.1  
ant/src/etc/testcases/taskdefs/optional/junitreport/NAMESPACE-sampleproject.namespace.xml
  
  Index: NAMESPACE-sampleproject.namespace.xml
  ===
  
  

  
  
  
  
  
  
  
  http://java.sun.com/";>
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  http://java.sun.com/cgi-bin/bugreport.cgi";>
  
  
  
  
  










  junit.framework.AssertionFailedError:
 DOEG
at sampleproject.coins.CoinTest.testFail(CoinTest.java:229)
  


  java.lang.RuntimeException: RTE
at sampleproject.coins.CoinTest.testException(CoinTest.java:234)
  




  
  
  
  
  1.1  
ant/src/etc/testcases/taskdefs/optional/junitreport/WRONGELEMENT-sampleproject.wrongelement.xml
  
  Index: WRONGELEMENT-sampleproject.wrongelement.xml
  ===
  
  
  
  
  
  1.1  
ant/src/etc/testcases/taskdefs/optional/junitreport/ZEROBYTES-sampleproject.package.xml
  
<>
  
  
  1.2   +44 -0 ant/src/etc/testcases/taskdefs/optional/junitreport.xml
  
  Index: junitreport.xml
  ===
  RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/optional/junitreport.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- junitreport.xml   26 Sep 2002 12:11:37 -  1.1
  +++ junitreport.xml   13 May 2005 21:42:23 -  1.2
  @@ -18,6 +18,50 @@
   
   
   
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
   
   
   
  
  
  
  1.34  +35 -18
ant/src/main/org/apache/tools/ant/taskdefs/optional/junit/XMLResultAggregator.java
  
  Index: XMLResultAggregator.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/junit/XMLResultAggregator.java,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- XMLResultAggregator.java  14 Mar 2005 09:19:50 -  1.33
  +++ XMLResultAggregator.java  13 May 2005 21:42:23 -  1.34
  @@ -77,6 +77,19 @@
   protected int generatedId = 0;
   
   /**
  + * text checked for in tests, [EMAIL PROTECTED]
  + */
  +static final String WARNING_IS_POSSIBLY_CORRUPTED = " is not a valid XML 
document. It is possibly corrupted.";
  +/**
  + * text checked for in tests, [EMAIL PROTECTED]
  + */
  +static final String WARNING_INVALID_ROOT_ELEMENT = " is not a valid 
testsuite XML document";
  +/**
  + * text checked for in tests, [EMAIL PROTECTED]
  + */
  +static final String WARNING_EMPTY_FILE = " is empty.\nThis can be caused 
by the test JVM exiting unexpectedly";
  +
  +/**
* Generate a report based on the document created by the merge.
* @return the report

cvs commit: ant/xdocs resources.xml

[stevel]

stevel  2005/05/13 13:49:10

  Modified:xdocsresources.xml
  Log:
  1. new books
  2. touched up old books
  3. stripped out my old email address. I now know why that alias still get so 
much virus/spam mail.
  
  Revision  ChangesPath
  1.42  +68 -13ant/xdocs/resources.xml
  
  Index: resources.xml
  ===
  RCS file: /home/cvs/ant/xdocs/resources.xml,v
  retrieving revision 1.41
  retrieving revision 1.42
  diff -u -r1.41 -r1.42
  --- resources.xml 13 Aug 2004 08:32:24 -  1.41
  +++ resources.xml 13 May 2005 20:49:10 -  1.42
  @@ -1,6 +1,6 @@
   
   
  +  The most recent books come first
  +
  +  
  +Published April 2005, and covers Ant release 1.6.1.
  +
  +This is a complete rewrite of the first edition; this book is
  +now 290 pages and so covers Ant in more depth than its predecessor.
  +
  +
  +It also mixes reference information (tables) with text explanation
  +on how to use the tasks. Contents includes JUnit, CVS, execution, 
basic
  +deployment, Web application development and XDoclet. There is also 
coverage
  +of XDoclet, and a chapter on how to extend Ant in Java.
  +
  +
  +  
  +Author:
  +Steve Holzner
  +  
  +  
  +URL:
  +
  +  http://www.oreilly.com/catalog/anttdg2/";>http://www.oreilly.com/catalog/anttdg2/
  +
  +  
  +
  +  
  +
  +  
  +
  +
  +How to Build, Deploy, and Monitor Java Applications.
  +Published: July 2004 ISBN:   0-9745140-3-9
  +
  +
  +  This is not a reference guide to Ant, but a book on how to 
automate the build process.
  +  The core build, continuous integration, reporting and release 
management
  +  are all covered. Ant is of course central to this. This is a fun 
read!
  +
  +
  +  
  +Author:
  +Mike Clark
  +  
  +  
  +URL:
  +
  +  http://www.pragmaticprogrammer.com/sk/auto/";>http://www.pragmaticprogrammer.com/sk/auto//
  +
  +  
  +
  +  
  +
  +
  +
 
 This book shows how to implement an XP project using Ant 1.5.3, 
and many other 3rd party tools.  Covers:
   
  @@ -134,6 +187,7 @@
   file operation
   source code control systems
   
  +The book is available in English as "Ant: The Java Build Tool in 
Practice"
   
 
   Authors:
  @@ -147,7 +201,7 @@
 
   
 
  -Covers Ant 1.5, including:
  +Published 2002. This book covers Ant 1.5, including:
   
   The new Ant 1.5 features
   Ant's datatypes and property handling
  @@ -167,6 +221,7 @@
   
   
   
  +Also available in Korean and German editions
   
   
 
  @@ -180,9 +235,9 @@
   
 
   
  -  
  +  
 
  -Covers Ant release 1.4.1.
  +Published 2002, Covers Ant release 1.4.1.
   
 
   Authors:
  @@ -346,7 +401,7 @@
   
 
   
  -  
  +  
   This article describes the main topics of programming your own 
tasks.
   Description is done on five examples.
   This article is written in German and published in
  @@ -372,7 +427,7 @@
   
 
   Author:
  -mailto:[EMAIL PROTECTED]">Steve Loughran
  +Steve Loughran
 
 
   URL:
  @@ -388,7 +443,7 @@
   
 
   Author:
  -mailto:[EMAIL PROTECTED]">Steve Loughran
  +Steve Loughran
 
 
   URL:
  @@ -649,14 +704,14 @@
 
   
 
  -This presentation is an overview of the current state of software
  -development today.  There are a couple of slides that briefly cover
  +This presentation is an overview of the state of software
  +development in 2001.  There are a couple of slides that briefly cover
   Ant.
   
   
 
   Author:
  -mailto:[EMAIL PROTECTED]">Steve Loughran
  +Steve Loughran
 
 
   URL:
  @@ -673,7 +728,7 @@
   
 
   Author:
  -mailto:[EMAIL PROTECTED]">Steve Loughran
  +Steve Loughran
 
 
   URL:
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTEC

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/compilers CompilerAdapter.java CompilerAdapterFactory.java Gcj.java Javac12.java Javac13.java JavacExternal.java Jikes.java Jvc.java Kjc.java Sj.

[peterreilly]

peterreilly2005/05/13 09:58:55

  Modified:src/main/org/apache/tools/ant/taskdefs/compilers
CompilerAdapter.java CompilerAdapterFactory.java
Gcj.java Javac12.java Javac13.java
JavacExternal.java Jikes.java Jvc.java Kjc.java
Sj.java
  Log:
  checkstyle - mostly javadoc
  
  Revision  ChangesPath
  1.13  +3 -1  
ant/src/main/org/apache/tools/ant/taskdefs/compilers/CompilerAdapter.java
  
  Index: CompilerAdapter.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/compilers/CompilerAdapter.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- CompilerAdapter.java  9 Mar 2004 16:48:13 -   1.12
  +++ CompilerAdapter.java  13 May 2005 16:58:55 -  1.13
  @@ -1,5 +1,5 @@
   /*
  - * Copyright  2001-2004 The Apache Software Foundation
  + * Copyright  2001-2005 The Apache Software Foundation
*
*  Licensed under the Apache License, Version 2.0 (the "License");
*  you may not use this file except in compliance with the License.
  @@ -37,6 +37,7 @@
   
   /**
* Sets the compiler attributes, which are stored in the Javac task.
  + * @param attributes the compiler attributes
*/
   void setJavac(Javac attributes);
   
  @@ -44,6 +45,7 @@
* Executes the task.
*
* @return has the compilation been successful
  + * @throws BuildException on error
*/
   boolean execute() throws BuildException;
   }
  
  
  
  1.30  +3 -1  
ant/src/main/org/apache/tools/ant/taskdefs/compilers/CompilerAdapterFactory.java
  
  Index: CompilerAdapterFactory.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/compilers/CompilerAdapterFactory.java,v
  retrieving revision 1.29
  retrieving revision 1.30
  diff -u -r1.29 -r1.30
  --- CompilerAdapterFactory.java   30 Mar 2005 08:35:43 -  1.29
  +++ CompilerAdapterFactory.java   13 May 2005 16:58:55 -  1.30
  @@ -27,7 +27,7 @@
*
* @since Ant 1.3
*/
  -public class CompilerAdapterFactory {
  +public final class CompilerAdapterFactory {
   private static final String MODERN_COMPILER = "com.sun.tools.javac.Main";
   
   /** This is a singleton -- can't create instances!! */
  @@ -55,6 +55,7 @@
* @param compilerType either the name of the desired compiler, or the
* full classname of the compiler's adapter.
* @param task a task to log through.
  + * @return the compiler adapter
* @throws BuildException if the compiler type could not be resolved into
* a compiler adapter.
*/
  @@ -145,6 +146,7 @@
   return true;
   }
   } catch (ClassNotFoundException cnfe2) {
  +// Ignore Exception
   }
   }
   return false;
  
  
  
  1.25  +7 -1  
ant/src/main/org/apache/tools/ant/taskdefs/compilers/Gcj.java
  
  Index: Gcj.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/compilers/Gcj.java,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- Gcj.java  27 Apr 2005 09:51:14 -  1.24
  +++ Gcj.java  13 May 2005 16:58:55 -  1.25
  @@ -33,6 +33,8 @@
   
   /**
* Performs a compile using the gcj compiler.
  + * @return true if the compilation succeeded
  + * @throws BuildException on error
*/
   public boolean execute() throws BuildException {
   Commandline cmd;
  @@ -46,6 +48,10 @@
   executeExternalCompile(cmd.getCommandline(), firstFileName) == 0;
   }
   
  +/**
  + * Set up the gcj commandline.
  + * @return the command line
  + */
   protected Commandline setupGCJCommand() {
   Commandline cmd = new Commandline();
   Path classpath = new Path(project);
  @@ -113,7 +119,7 @@
   /**
* Whether any of the arguments given via 
* implies that compilation to native code is requested.
  - *
  + * @return true if compilation to native code is requested
* @since Ant 1.6.2
*/
   public boolean isNativeBuild() {
  
  
  
  1.18  +2 -2  
ant/src/main/org/apache/tools/ant/taskdefs/compilers/Javac12.java
  
  Index: Javac12.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/compilers/Javac12.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- Javac12.java  9 Mar 2004 16:48:13 -   1.17
  +++ Javac12.java  13 May 2005 16:58:55 -  1.18
  @@ -1,5 +1,5 @@
   /*
  - * 

Re: [Bug 28444] - Import: Target Handling Bug

[Phil Weighill Smith]

Rather than having a specific  element, could this not
be achieved via a naming convention such as "-target-name" (the leading
"-" actually makes the target uninvocable from the command line anyway
and therefore pretty good and private from the CLI point-of-view)?

Or even a new attribute on target that indicates that it is "private"?

Phil :n.

On Fri, 2005-05-13 at 17:18 +0100, Peter Reilly wrote:
> Jose Alberto Fernandez wrote:
> 
> >Just to put closure in my list of peeves about ,
> >I really think we need a way to define "private" targets.
> >  
> >
> +1, one should be able to write an importable build file that has
> some exported targets - but internally uses targets that do not get
> overwritten accidently.
> 
> Peter
> 
> >Now, for this to work properly, you need:
> >
> >1) A way to mark a target as private.
> >2) private targets must be ignored by targets of the same names on other
> >
> >points in the hierarchy.
> >3) Depends on a private target must be resolved by the correct instance
> >of the target.
> >
> >So lets assume the following syntax:
> >
> > ...
> >
> >foo.xml
> >
> >   >message="compiling"/>
> >
> >
> >bar.xml
> >
> >  
> >   >message="building"/>
> >  
> >
> >
> >baz.xml
> >
> >  
> >  
> >
> >
> >ant compile
> >  prepare compile
> >  compiling
> >
> >ant build
> >  prepare build
> >  building
> >
> >Here: 
> >foo.xml is like an abstract project which does not define "setup";
> >bar.xml's setup is private to bar1 and will not be used by the
> >dependency in foo1
> >baz.xml overrides (defines in this case) the setup target used in foo1
> >but not the one in bar1.
> >
> >The rewriting rules are a bit tricky, because for every private target
> >you need to use a new "private name" for it, and change all the
> >occurencies
> >in dependencies on that file of the name, for the new name.
> >
> >Seems actually doable.
> >
> >Jose Alberto
> >
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >  
> >
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 28444] - Import: Target Handling Bug

[Peter Reilly]

Jose Alberto Fernandez wrote:
Just to put closure in my list of peeves about ,
I really think we need a way to define "private" targets.
 

+1, one should be able to write an importable build file that has
some exported targets - but internally uses targets that do not get
overwritten accidently.
Peter
Now, for this to work properly, you need:
1) A way to mark a target as private.
2) private targets must be ignored by targets of the same names on other
points in the hierarchy.
3) Depends on a private target must be resolved by the correct instance
of the target.
So lets assume the following syntax:
...
foo.xml

 

bar.xml

 
 
 

baz.xml

 
 

ant compile
 prepare compile
 compiling
ant build
 prepare build
 building
Here: 
foo.xml is like an abstract project which does not define "setup";
bar.xml's setup is private to bar1 and will not be used by the
dependency in foo1
baz.xml overrides (defines in this case) the setup target used in foo1
but not the one in bar1.

The rewriting rules are a bit tricky, because for every private target
you need to use a new "private name" for it, and change all the
occurencies
in dependencies on that file of the name, for the new name.
Seems actually doable.
Jose Alberto

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34826] - ORA-00600 running SQLExec w/ keepformat="true"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34826


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-05-13 18:08 ---
Confirmed an Oracle Bug. Closing. 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Commercial products on the "related products" page?

[Erik Hatcher]

I had hopes that we'd use the wiki for this sort of stuff in the  
future, allowing it to be self-serve.  The downside is that it's not  
included in the current distributions, but we could probably do some  
sort of  to pull wiki content into distributions as a snapshot.

Erik
On May 13, 2005, at 8:12 AM, Stefan Bodewig wrote:
Hi,
Slava Imeshev of Viewtier Systems sent me a private email asking
whether it was OK to include links to commercial products on our
"related projects" page.  The original email - minus the actual patch
and Slava's phone number - is reproduced below (with Slava's
permission, of course).
We already point to commercial IDEs for example, so I don't see any
reason why we shouldn't do so for a buildserver, but maybe you feel
different about it?
Cheers
Stefan

From: "Slava Imeshev" <[EMAIL PROTECTED]>
Subject: Patch to /ant/xdocs/projects.xml
To: "Stefan Bodewig" <[EMAIL PROTECTED]>
Date: Thu, 12 May 2005 23:49:35 -0700
Organization: Viewtier Systems, Inc.
Hello Stefan,
I was wondering if you accept commercial additions to the Ant  
Related Projects
page at /ant/xdocs/projects.xml.

If this is the case, I'd like to suggest a patch (enclosed) that  
adds Parabuild to
/ant/xdocs/projects.xml. Parabuild is a multiplatform build  
automation server.
Ant users are our main target audience. The URL of the product  
home is
http://www.viewtier.com/products/parabuild/index.htm

Please don't hesitate to contact me if you have any questions.
Regards,
Slava Imeshev
President
Viewtier Systems, Inc.
800 West El Camino Real, Suite 180
Mountain View, CA, 94040
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [Bug 28444] - Import: Target Handling Bug

[Jose Alberto Fernandez]

Just to put closure in my list of peeves about ,
I really think we need a way to define "private" targets.

Now, for this to work properly, you need:

1) A way to mark a target as private.
2) private targets must be ignored by targets of the same names on other

points in the hierarchy.
3) Depends on a private target must be resolved by the correct instance
of the target.

So lets assume the following syntax:

 ...

foo.xml

  


bar.xml

  
  
  


baz.xml

  
  


ant compile
  prepare compile
  compiling

ant build
  prepare build
  building

Here: 
foo.xml is like an abstract project which does not define "setup";
bar.xml's setup is private to bar1 and will not be used by the
dependency in foo1
baz.xml overrides (defines in this case) the setup target used in foo1
but not the one in bar1.

The rewriting rules are a bit tricky, because for every private target
you need to use a new "private name" for it, and change all the
occurencies
in dependencies on that file of the name, for the new name.

Seems actually doable.

Jose Alberto



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34907] New: - Add Multipart subtype setting to MimeMailer

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34907

   Summary: Add Multipart subtype setting to MimeMailer
   Product: Ant
   Version: 1.6.3
  Platform: All
OS/Version: other
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: Optional Tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


Hi,
A mime mail multipart can be 'mixed', 'alternative' or 'related'. However, it
seems that ant's MimeMultipart class always takes the default ('mixed').
Is it possible to allow the setting of this subtype?
I guess that would allow for example, sending an html email which has images
embedded.
Patrick M.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 28444] - Import: Target Handling Bug

[Evan Easton]

Anyone consider:

...

Nicola Ken Barozzi wrote:
Jose Alberto Fernandez wrote:
Going to the old discussions in how to approach this issues,
the thing that bother me most, is that in order to get access
to an imported target I need to know the name given to the project
on the file that did the import.
This in my opinion contradicts the hidding rules of OO programming.
I should not need to know about the internals of an imported object.
It also means that I have to coordinate all the files I may directly
or indirectly import so that there is no project name clashes.

You could make the argument that the name isn't really an internal.  
It's just an alias to reference the project since using the filename 
might not be desirable.  Java and some other languages base the name of 
a class or module on the file or require the two to be the same.  But 
what about C++, and probably others.  You can declare whatever classes 
you want in a .h file with any name and yet you still expect the user to 
include some "file name" (e.g. ) and then use classes defined 
inside that file which may hve difference names (e.g. stringbuf, 
ostringstream,...).

Some of the information defined inside the imported build file has to be 
accessible to the outside.  It seems reasonable that, just like the 
target names, macro, presets, tasks, selectors, properties,  the 
project name could be one more piece of useful information.  You just 
now have to be careful not to rename the project if others might be 
importing your build filejust like any resource, in any 
imported/included file, is virtually any language.

Evan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 28444] - Import: Target Handling Bug

[Evan Easton]

Evan Easton wrote:
...
Valid point.
But isn't the depends list of an imported target something that you'd 
really like to not muck with in the interests of encapsulation?  I 
agree that it would be really nice to be able to insert into or at the 
end of the overridden target's dependencies (a la aspect oriented 
languages), but I think I could contrive cases where this 
unintentionally breaks the functionality of the overridden target.
I'm not saying it shouldn't be supported, but I think we are sill 
grappling with a basic OO-link inheritance problem that we need to 
address before diving into aspect oriented constructs which, while 
very powerful, seem to create lots of issues unless you really know 
what you're doing.
BTW,
While I don't think ant should become a polymorphic OO language, I do 
think that this override bug should be addressed by following 
conventions present in most OO languages. This is mostly because I'd 
like to not have to remember yet another oddball inheritance/override 
model and with a pure virtual, polymorphic model I'd know exactly what 
I'm doing.  Of course, since I've been coding for 20 years, I'm not 
really sure that this make things easier on newbies.  Plus there's 
the whole multiple inheritance debate to have all over again.
Evan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

[Peter Reilly]

Jose Alberto Fernandez wrote:
From: Peter Reilly [mailto:[EMAIL PROTECTED] 

Matt Benson wrote:
   

I can't imagine a scenario where BC would be
compromised, but I'd be glad for an example.
-Matt

 

I was thinking of the example with multiple import files with 
the same projectname/targetname.

example:
a.xml a.xml
b.xml b.xml
c.xml c.xml
build.xml

  
  
  

In this case, ant 1.6.x (and my patch) will output.
ant t
 will output "a.xml"
ant p.t
 will output "c.xml"
   

Ok, your example confused me. What is p.t p is not imported, why would
we have a p.t target?
 

I am talking about the current ant (1.6.x) implemention of import.
If an imported file does not have a project name, it "inherits" the 
project name it
uses in the target name from the importing project.

Peter
I do not understand why you get different answers for "p.t" and "t" is
the same target on
the same project (is it not?).
Did you meant  on the imported? Then I see what you
are saying.
Although it is probably difficult to avoid given the fact that 
is an
executed task. But hey, more reason for adding 'as' since otherwise
there is no
way to disambiguate appart from changing the imported files. :-P
Jose Alberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 28444] - Import: Target Handling Bug

[Evan Easton]

Anyone consider:

...

Nicola Ken Barozzi wrote:
Jose Alberto Fernandez wrote:
Going to the old discussions in how to approach this issues,
the thing that bother me most, is that in order to get access
to an imported target I need to know the name given to the project
on the file that did the import.
This in my opinion contradicts the hidding rules of OO programming.
I should not need to know about the internals of an imported object.
It also means that I have to coordinate all the files I may directly
or indirectly import so that there is no project name clashes.

You could make the argument that the name isn't really an internal.  
It's just an alias to reference the project since using the filename 
might not be desirable.  Java and some other languages base the name of 
a class or module on the file or require the two to be the same.  But 
what about C++, and probably others.  You can declare whatever classes 
you want in a .h file with any name and yet you still expect the user to 
include some "file name" (e.g. ) and then use classes defined 
inside that file which may hve difference names (e.g. stringbuf, 
ostringstream,...).

Some of the information defined inside the imported build file has to be 
accessible to the outside.  It seems reasonable that, just like the 
target names, macro, presets, tasks, selectors, properties,  the 
project name could be one more piece of useful information.  You just 
now have to be careful not to rename the project if others might be 
importing your build filejust like any resource, in any 
imported/included file, is virtually any language.

Evan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 28444] - Import: Target Handling Bug

[Steve Loughran]

Nicola Ken Barozzi wrote:
Steve Loughran wrote:
Phil Weighill-Smith wrote:
I missed the beginning of this thread but just want to say that I 
personally think that import is the best feature in Ant today (apart 
from Ant's being in the first place, that is)!

I find it hard to work with in a big project.
problems
-risk of adding a new target in an imported build file conflicting 
with one in the importer (i.e. lack of private scope)
 >
-when you override a target, you dont get access to its dependents. 
Workaround: many pseudo-targets that only model dependencies.

Could you please explain more? TIA
Imagine I have a base build file with a target "compile". If I overwrite 
it in a project, I need to manually redeclare all dependencies of the 
compile target

base
...
extension
...

That is, I need to know and declare the dependencies again. If I change 
the dependencies of the base target, all derived files need updating. 
What I want to say is

...

The workaround is pseudo targets

...
and then depend on the pre-compile target in derived build files
...

-once you have sub-projects importing ../../common.xml, they are no 
longer self contained, which makes it harder to work with outside the 
existing build tree.

I dont see any good solution for the latter.

The first and the last "problems" are in fact worksforme, as the import 
task is *intended* to pollute the project files that use it to be able 
to work as needed.
yes, but I dont always want to pollute project files with my inner 
workings.

In most cases, one would want to use ,  or  
instead of importing buildfiles with s, which should be used 
only to reuse and "extend" a base buildfile.
macrodef/presetdef defines standard actions; the base buildfile defines 
the standard process.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 28444] - Import: Target Handling Bug

[Evan Easton]

Stefan Bodewig wrote:
On Fri, 13 May 2005, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
 

Well, alternatively you could overide "setup":
   

Sure, we can certainly play fetch-me-a-rock here.  I just need to come
up with a more complex scenario and there will be no solution for it
in which I didn't have to duplicate (partial) depends lists or
introduce empty targets.
Stefan
 

Valid point.
But isn't the depends list of an imported target something that you'd 
really like to not muck with in the interests of encapsulation?  I agree 
that it would be really nice to be able to insert into or at the end of 
the overridden target's dependencies (a la aspect oriented languages), 
but I think I could contrive cases where this unintentionally breaks the 
functionality of the overridden target. 

I'm not saying it shouldn't be supported, but I think we are sill 
grappling with a basic OO-link inheritance problem that we need to 
address before diving into aspect oriented constructs which, while very 
powerful, seem to create lots of issues unless you really know what 
you're doing.

Evan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

[Jose Alberto Fernandez]

> From: Peter Reilly [mailto:[EMAIL PROTECTED] 
> 
> Matt Benson wrote:
> 
> >I can't imagine a scenario where BC would be
> >compromised, but I'd be glad for an example.
> >
> >-Matt
> >
> >  
> >
> I was thinking of the example with multiple import files with 
> the same projectname/targetname.
> 
> example:
> a.xml a.xml
> b.xml b.xml
> c.xml c.xml
> build.xml
> 
>
>
>
> 
> 
> In this case, ant 1.6.x (and my patch) will output.
> 
> ant t
>   will output "a.xml"
> ant p.t
>   will output "c.xml"
> 

Ok, your example confused me. What is p.t p is not imported, why would
we have a p.t target?
I do not understand why you get different answers for "p.t" and "t" is
the same target on
the same project (is it not?).

Did you meant  on the imported? Then I see what you
are saying.
Although it is probably difficult to avoid given the fact that 
is an
executed task. But hey, more reason for adding 'as' since otherwise
there is no
way to disambiguate appart from changing the imported files. :-P

Jose Alberto

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Commercial products on the "related products" page?

[Steve Loughran]

Stefan Bodewig wrote:
Hi,
Slava Imeshev of Viewtier Systems sent me a private email asking
whether it was OK to include links to commercial products on our
"related projects" page.  The original email - minus the actual patch
and Slava's phone number - is reproduced below (with Slava's
permission, of course).
We already point to commercial IDEs for example, so I don't see any
reason why we shouldn't do so for a buildserver, but maybe you feel
different about it?
Cheers
I'm happy with it, just mark it as commercial. But we need to reserve 
the right to change our policy in future,
just in case we ever change our mind.

Having a look at external.xml, I think it is time we did an 
update/cleanup of there. IDEA is listed at v2.0, for example.

Someone needs to update the resources page with Ant: TDG second edition, 
which is based on Ant1.6.1, and a complete rewrite of the 1st edition. I 
could do it, but run the risk of being slightly biased against it. I'll 
add an entry on Pragmatic Automation though; I love that book.

Stefan

From: "Slava Imeshev" <[EMAIL PROTECTED]>
Subject: Patch to /ant/xdocs/projects.xml
To: "Stefan Bodewig" <[EMAIL PROTECTED]>
Date: Thu, 12 May 2005 23:49:35 -0700
Organization: Viewtier Systems, Inc.
Hello Stefan,
I was wondering if you accept commercial additions to the Ant Related Projects 
page at /ant/xdocs/projects.xml.

If this is the case, I'd like to suggest a patch (enclosed) that adds Parabuild to 
/ant/xdocs/projects.xml. Parabuild is a multiplatform build automation server. 
Ant users are our main target audience. The URL of the product home is 
http://www.viewtier.com/products/parabuild/index.htm

Please don't hesitate to contact me if you have any questions.
Regards,
Slava Imeshev
President
Viewtier Systems, Inc.
800 West El Camino Real, Suite 180
Mountain View, CA, 94040

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

[Peter Reilly]

Matt Benson wrote:
I can't imagine a scenario where BC would be
compromised, but I'd be glad for an example.
-Matt
 

I was thinking of the example with multiple import files with
the same projectname/targetname.
example:
a.xml a.xml
b.xml b.xml
c.xml c.xml
build.xml

  
  
  

In this case, ant 1.6.x (and my patch) will output.
ant t
 will output "a.xml"
ant p.t
 will output "c.xml"

Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 28444] - Import: Target Handling Bug

[Stefan Bodewig]

On Fri, 13 May 2005, Peter Reilly <[EMAIL PROTECTED]> wrote:
> Stefan Bodewig wrote:

>>Do we really need to create a complete clone?  Can't we achieve the
>>same with a more lazy approach?
>>
>>Turning Matt's idea around:
>
> I do not see what that will buy us much in terms of efficeny.

Frankly, neither do I.  I don't have a real problem with your cloning
approach either.

> However, there should be no need to replace the placeholder as the
> overridding targets are processed first.

Yes, Matt already told me that my memory was failing on me.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [Bug 28444] - Import: Target Handling Bug

[Jose Alberto Fernandez]

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
> 
> On Fri, 13 May 2005, Jose Alberto Fernandez 
> <[EMAIL PROTECTED]> wrote:
> 
> > Well, alternatively you could overide "setup":
> 
> Sure, we can certainly play fetch-me-a-rock here.  I just 
> need to come up with a more complex scenario and there will 
> be no solution for it in which I didn't have to duplicate 
> (partial) depends lists or introduce empty targets.
> 

In any case, I know what you mean. The difference that we have with
regular OO procedural languages is that we need to refer to the
dependencies
in the inheritance and we do not have a way to express that.
Although the notation bellow is wrong, what you would like is something
like:



I do not like ${depends-of:...} because it looks too much like something
evaluated dynamically,
which may be the case, but then people will want to be able to use
properties and that is a 
no-no for me.

We could generate something like:



and then you are able to say:



The target "imported.compile:depends" should be generated by .

This may duplicate the amount of targets, which may be not nice, but we
could have something
on  to request this depends targets. Something like:



This will add the additional targets "imported.compile:depends" and
"imported.build:depends".

What do you think? Too complicated?

Jose Alberto


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 28444] - Import: Target Handling Bug

[Peter Reilly]

Stefan Bodewig wrote:
On Thu, 12 May 2005, Peter Reilly <[EMAIL PROTECTED]> wrote:
 

The target gets renamed if there another target of the same name,
but not otherwise - how can one write a proper reusable import file
using the rename feature in this case?
   

I'm strongly +1 for at least providing renamed aliases for all
targets, independent on how we achieve that.
 

The fix will have a small overhead - the target object needs to be
cloned and given a a new name, whereas the current code just renames
the target object.
   

Do we really need to create a complete clone?  Can't we achieve the
same with a more lazy approach?
Turning Matt's idea around:
(1) Target "foo" is in project "bar".
(2a) There already is a target "foo" from the file that imported
"bar", use the current code, we are ready, "bar.foo" is there.
(2b) There is no other target "foo" yet.  Create an empty placeholder
target "bar.foo" that depends on "foo".
If then later a target "foo" is found in the importing buildfile,
replace the placeholder "bar.foo" with the initial "foo" target.
 

I do not see what that will buy us much in terms of efficeny. However, 
there should be
no need to replace the placeholder as the overridding targets are 
processed first.


Wouldn't that work, stay backwards compatible and hide "bar." whenever
possible?
 

Yes.. I think so.
Peter
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: Commercial products on the "related products" page?

[Jan . Materne]

What - the most important snippet you had forgotten???   :-O

Jan

> -Ursprüngliche Nachricht-
> Von: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Gesendet am: Freitag, 13. Mai 2005 14:20
> An: dev@ant.apache.org
> Betreff: Re: Commercial products on the "related products" page?
> 
> A snippet I forgot to forward 8-)
> 
> > Using this chance I'd like to say you guys did really good job with 
> > Ant - I think it is one of the best Java products out there.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

Re: Commercial products on the "related products" page?

[Stefan Bodewig]

A snippet I forgot to forward 8-)

> Using this chance I'd like to say you guys did really good job with 
> Ant - I think it is one of the best Java products out there.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: Commercial products on the "related products" page?

[Jan . Materne]

Should be ok. License information is for each entry present.
Maybe we should split external&related into free/commercial sections ... if
there
are more entries.

Jan

> -Ursprüngliche Nachricht-
> Von: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Gesendet am: Freitag, 13. Mai 2005 14:12
> An: dev@ant.apache.org
> Betreff: Commercial products on the "related products" page?
> 
> Hi,
> 
> Slava Imeshev of Viewtier Systems sent me a private email asking
> whether it was OK to include links to commercial products on our
> "related projects" page.  The original email - minus the actual patch
> and Slava's phone number - is reproduced below (with Slava's
> permission, of course).
> 
> We already point to commercial IDEs for example, so I don't see any
> reason why we shouldn't do so for a buildserver, but maybe you feel
> different about it?
> 
> Cheers
> 
> Stefan
> 
> > From: "Slava Imeshev" <[EMAIL PROTECTED]>
> > Subject: Patch to /ant/xdocs/projects.xml
> > To: "Stefan Bodewig" <[EMAIL PROTECTED]>
> > Date: Thu, 12 May 2005 23:49:35 -0700
> > Organization: Viewtier Systems, Inc.
> > 
> > Hello Stefan,
> > 
> > I was wondering if you accept commercial additions to the 
> Ant Related Projects 
> > page at /ant/xdocs/projects.xml.
> > 
> > If this is the case, I'd like to suggest a patch (enclosed) 
> that adds Parabuild to 
> > /ant/xdocs/projects.xml. Parabuild is a multiplatform build 
> automation server. 
> > Ant users are our main target audience. The URL of the 
> product home is 
> > http://www.viewtier.com/products/parabuild/index.htm
> > 
> > Please don't hesitate to contact me if you have any questions.
> > 
> > Regards,
> > 
> > Slava Imeshev
> > President
> > Viewtier Systems, Inc.
> > 800 West El Camino Real, Suite 180
> > Mountain View, CA, 94040
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

Commercial products on the "related products" page?

[Stefan Bodewig]

Hi,

Slava Imeshev of Viewtier Systems sent me a private email asking
whether it was OK to include links to commercial products on our
"related projects" page.  The original email - minus the actual patch
and Slava's phone number - is reproduced below (with Slava's
permission, of course).

We already point to commercial IDEs for example, so I don't see any
reason why we shouldn't do so for a buildserver, but maybe you feel
different about it?

Cheers

Stefan

> From: "Slava Imeshev" <[EMAIL PROTECTED]>
> Subject: Patch to /ant/xdocs/projects.xml
> To: "Stefan Bodewig" <[EMAIL PROTECTED]>
> Date: Thu, 12 May 2005 23:49:35 -0700
> Organization: Viewtier Systems, Inc.
> 
> Hello Stefan,
> 
> I was wondering if you accept commercial additions to the Ant Related 
> Projects 
> page at /ant/xdocs/projects.xml.
> 
> If this is the case, I'd like to suggest a patch (enclosed) that adds 
> Parabuild to 
> /ant/xdocs/projects.xml. Parabuild is a multiplatform build automation 
> server. 
> Ant users are our main target audience. The URL of the product home is 
> http://www.viewtier.com/products/parabuild/index.htm
> 
> Please don't hesitate to contact me if you have any questions.
> 
> Regards,
> 
> Slava Imeshev
> President
> Viewtier Systems, Inc.
> 800 West El Camino Real, Suite 180
> Mountain View, CA, 94040

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 30706] - Ftp task unable to get or list

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=30706





--- Additional Comments From [EMAIL PROTECTED]  2005-05-13 14:10 ---
This should now be fixed with the latest (1.4.0) release of Commons-Net.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 28444] - Import: Target Handling Bug

[Stefan Bodewig]

On Fri, 13 May 2005, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:

> Well, alternatively you could overide "setup":

Sure, we can certainly play fetch-me-a-rock here.  I just need to come
up with a more complex scenario and there will be no solution for it
in which I didn't have to duplicate (partial) depends lists or
introduce empty targets.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [Bug 28444] - Import: Target Handling Bug

[Jose Alberto Fernandez]

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
> 
> On Fri, 13 May 2005, Jose Alberto Fernandez 
> <[EMAIL PROTECTED]> wrote:
> >> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> 
> >> Another related problem I have is that you can't add
> >> something to the beginning of a target easily.  You can add 
> >> someting to the end of "foo" by writing your own "foo" that 
> >> depends on "imported.foo", but if you want to add something 
> >> at the start your imported build file has to be designed for 
> >> it.  Which means pseudo-targets that are used as interception 
> >> points only.
> >> 
> > 
> > Cant you write on the importing file:
> > 
> > 
> > 
> > ...
> 
> Not if I want to inject stuff between the targets 
> "imported.foo" depends on and "imported.foo" itself.
> 
> imported.xml
> 
> ,
> | 
> |   ...
> | 
> | 
> | 
> |   
> | 
> `
> 
> build.xml
> 
> ,
> | 
> |   
> | 
> `
> 
> how do I get the build sequence imported.setup, 
> generate-java-from-idl, compile without modifying 
> imported.xml and without access to the dependencies of "compile"?
> 
> Today I either add depends="setup" to 
> "generate-java-from-idl" and have to change that whenever the 
> depends list of "compile" changes or I introduce an empty 
> target to imported.xml, make "compile" depend on it (as the 
> last target in the list) and the override this empty target 
> with "generate-java-from-idl".
> 

Well, alternatively you could overide "setup":

  

Actually, one could argue that generate-java-from-idl is part of the
setup 
for "compile" in this context and hence that is the correct target to
override.

Jose Alberto

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 28444] - Import: Target Handling Bug

[Nicola Ken Barozzi]

Jose Alberto Fernandez wrote:
Going to the old discussions in how to approach this issues,
the thing that bother me most, is that in order to get access
to an imported target I need to know the name given to the project
on the file that did the import.
This in my opinion contradicts the hidding rules of OO programming.
I should not need to know about the internals of an imported object.
It also means that I have to coordinate all the files I may directly
or indirectly import so that there is no project name clashes. 
Java imports packages that have to be unique based on a naming 
convention; AFAIK if package names are not unique, you have clashes.
Unfortunately now it's too late to reccomend a naming convention.

I would advocate to allow the importer the specify the aliasing name it 
wants to use for the imported things, so one has something like:
...
  
Very nice, I like it.
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 28444] - Import: Target Handling Bug

[Stefan Bodewig]

On Fri, 13 May 2005, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
>> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 

>> Another related problem I have is that you can't add 
>> something to the beginning of a target easily.  You can add 
>> someting to the end of "foo" by writing your own "foo" that 
>> depends on "imported.foo", but if you want to add something 
>> at the start your imported build file has to be designed for 
>> it.  Which means pseudo-targets that are used as interception 
>> points only.
>> 
> 
> Cant you write on the importing file:
> 
> 
> 
> ...

Not if I want to inject stuff between the targets "imported.foo"
depends on and "imported.foo" itself.

imported.xml

,
| 
|   ...
| 
| 
| 
|   
| 
`

build.xml

,
| 
|   
| 
`

how do I get the build sequence imported.setup,
generate-java-from-idl, compile without modifying imported.xml and
without access to the dependencies of "compile"?

Today I either add depends="setup" to "generate-java-from-idl" and
have to change that whenever the depends list of "compile" changes or
I introduce an empty target to imported.xml, make "compile" depend on
it (as the last target in the list) and the override this empty target
with "generate-java-from-idl".

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [Bug 28444] - Import: Target Handling Bug

[Jose Alberto Fernandez]

> From: Phil Weighill Smith [mailto:[EMAIL PROTECTED] 
> 
> On Fri, 2005-05-13 at 11:38 +0100, Jose Alberto Fernandez wrote:
> > I would advocate to allow the importer the specify the 
> aliasing name 
> > it wants to use for the imported things, so one has something like:
> > 
> > foo.xml
> > 
> >   ...
> > 
> > 
> > bar.xml
> > 
> >   
> >   ...
> > 
> 
> +1 to the 'as=""'.
> 
> Would we still be able to reference "imp1.compile" as just 
> "compile" if the target has not been overridden in the 
> importing build script: I think this is very important to maintain.

Yes, you would have a "compile" target which is the realization of the
inheritance:

 

Or something like that, the question is what you get if there are
ambiguities due to multiple imports (you may get just the first one, or
an error)
unless you override and specify what you want them to do.

Jose Alberto

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [Bug 28444] - Import: Target Handling Bug

[Phil Weighill Smith]

On Fri, 2005-05-13 at 11:38 +0100, Jose Alberto Fernandez wrote:
> I would advocate to allow the importer the specify the aliasing name
> it 
> wants to use for the imported things, so one has something like:
> 
> foo.xml
> 
>   ...
> 
> 
> bar.xml
> 
>   
>   ...
> 

+1 to the 'as=""'.

Would we still be able to reference "imp1.compile" as just "compile" if
the target has not been overridden in the importing build script: I
think this is very important to maintain.

Phil :n.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [Bug 28444] - Import: Target Handling Bug

[Jose Alberto Fernandez]

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
> Sent: 13 May 2005 11:10
> To: dev@ant.apache.org
> Subject: Re: [Bug 28444] - Import: Target Handling Bug
> 
> 
> Another related problem I have is that you can't add 
> something to the beginning of a target easily.  You can add 
> someting to the end of "foo" by writing your own "foo" that 
> depends on "imported.foo", but if you want to add something 
> at the start your imported build file has to be designed for 
> it.  Which means pseudo-targets that are used as interception 
> points only.
> 

Cant you write on the importing file:



...

Or was that what you meant? Notice that the imported file does not
need to know about it.

Jose Alberto

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 28444] - Import: Target Handling Bug

[Phil Weighill Smith]

On Fri, 2005-05-13 at 10:25 +0100, Steve Loughran wrote:
> -when you override a target, you dont get access to its dependents. 
> Workaround: many pseudo-targets that only model dependencies.

In fact we have "real" targets that don't have dependencies and it is
these that we override. These are also useful, in large projects, when
you know you've made a change that doesn't require a complete dependency
build to be performed.







Again we find this useful as a developer may be updating (internal) code
in one subsystem only and this allows us to avoid a four or five minute
delay while Ant and Java work out exactly which classes need to be re-
built across the whole project. Clearly the developer directly uses "no
dependency" targets at their own risk as there could be dependencies
that really do need to be processed.

> -once you have sub-projects importing ../../common.xml, they are no 
> longer self contained, which makes it harder to work with outside the 
> existing build tree.

We address this by having a wrapper for (or alias to) ant that
specifically sets a property that points to the "common.xml"'s location
so as long as that location exists and has "common.xml" in it all is
fine.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [Bug 28444] - Import: Target Handling Bug

[Jose Alberto Fernandez]

Going to the old discussions in how to approach this issues,
the thing that bother me most, is that in order to get access
to an imported target I need to know the name given to the project
on the file that did the import.

This in my opinion contradicts the hidding rules of OO programming.
I should not need to know about the internals of an imported object.
It also means that I have to coordinate all the files I may directly
or indirectly import so that there is no project name clashes. 

I would advocate to allow the importer the specify the aliasing name it 
wants to use for the imported things, so one has something like:

foo.xml

  ...


bar.xml

  
  ...


baz.xml

  
  ...
  

  


The point being that the user of the imports is the one deciding how to
refer to
the targets in its own local file. For BC, is no 'as' attribute is
specified we
can use the imported project name.

At implementation, what we need to do is for every imported target,
rewrite their names
and add an empty target with the original name, if not already
overriden.

I think that is all that is necessary.

Jose Alberto

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
> Sent: 12 May 2005 20:35
> To: dev@ant.apache.org
> Subject: Re: [Bug 28444] - Import: Target Handling Bug
> 
> 
> On Thu, 12 May 2005, Peter Reilly <[EMAIL PROTECTED]> wrote:
> 
> > The target gets renamed if there another target of the same 
> name, but 
> > not otherwise - how can one write a proper reusable import 
> file using 
> > the rename feature in this case?
> 
> I'm strongly +1 for at least providing renamed aliases for 
> all targets, independent on how we achieve that.
> 
> > The fix will have a small overhead - the target object needs to be 
> > cloned and given a a new name, whereas the current code 
> just renames 
> > the target object.
> 
> Do we really need to create a complete clone?  Can't we 
> achieve the same with a more lazy approach?
> 
> Turning Matt's idea around:
> 
> (1) Target "foo" is in project "bar".
> (2a) There already is a target "foo" from the file that imported
>  "bar", use the current code, we are ready, "bar.foo" is there.
> (2b) There is no other target "foo" yet.  Create an empty placeholder
>  target "bar.foo" that depends on "foo".
> 
>  If then later a target "foo" is found in the importing buildfile,
>  replace the placeholder "bar.foo" with the initial "foo" target.
> 
> Wouldn't that work, stay backwards compatible and hide "bar." 
> whenever possible?
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java

[scohen]

scohen  2005/05/13 03:34:40

  Modified:src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java
  Log:
  improve clarity of what FTPConfigurator is doing.
  
  Revision  ChangesPath
  1.70  +3 -7  
ant/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java
  
  Index: FTP.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java,v
  retrieving revision 1.69
  retrieving revision 1.70
  diff -u -r1.69 -r1.70
  --- FTP.java  13 May 2005 10:26:20 -  1.69
  +++ FTP.java  13 May 2005 10:34:40 -  1.70
  @@ -2067,12 +2067,6 @@
   }
   }
   
  -private void configure(FTPClient ftp) {
  -if (this.isConfigurationSet) {
  -FTPConfigurator.configure(ftp, this);
  -}
  -}
  -
   /**
* Runs the task.
*
  @@ -2088,7 +2082,9 @@
   log("Opening FTP connection to " + server, Project.MSG_VERBOSE);
   
   ftp = new FTPClient();
  -configure(ftp);
  +if (this.isConfigurationSet) {
  +ftp = FTPConfigurator.configure(ftp, this);
  +}
   
   ftp.connect(server, port);
   if (!FTPReply.isPositiveCompletion(ftp.getReplyCode())) {
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/docs/manual install.html

[Steve Cohen]

Stefan Bodewig wrote:
On Thu, 12 May 2005, Steve Cohen <[EMAIL PROTECTED]> wrote:

I don't know, though, guys.  What do you think?  Is it really worth
it to avoid making the users upgrade?

For me it depends on when you wanted to see the new task.
If you wanted to include it in 1.6.4 (which is unlikely to happen
anyway, given Steve's and Matt's comments) then you wouldn't get a +1
from me if it forced people to upgrade commons-net.  This is just too
fresh IMHO.
If you are shooting for 1.7, having the code depend on commons-net
1.4.x is fine with me.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Well, I've done it.  1.4.0 is no longer required.  Have a look.  It 
isn't too ugly.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/docs/manual install.html

[scohen]

scohen  2005/05/13 03:26:20

  Modified:src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java
   docs/manual install.html
  Added:   src/main/org/apache/tools/ant/taskdefs/optional/net
FTPConfigurator.java
  Log:
  Add FTPConfigurator class so as to avoid forcing users to upgrade to version 
1.4.0 of commons-net.
  As long as users use the ftp task as they have previously, they do not need 
1.4.0.
  
  Revision  ChangesPath
  1.69  +48 -37
ant/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java
  
  Index: FTP.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java,v
  retrieving revision 1.68
  retrieving revision 1.69
  diff -u -r1.68 -r1.69
  --- FTP.java  12 May 2005 04:04:59 -  1.68
  +++ FTP.java  13 May 2005 10:26:20 -  1.69
  @@ -17,7 +17,6 @@
   package org.apache.tools.ant.taskdefs.optional.net;
   
   import org.apache.commons.net.ftp.FTPClient;
  -import org.apache.commons.net.ftp.FTPClientConfig;
   import org.apache.commons.net.ftp.FTPFile;
   import org.apache.commons.net.ftp.FTPReply;
   import java.io.BufferedInputStream;
  @@ -1323,11 +1322,47 @@
   
   
   /**
  + * @return Returns the systemKeyConfig.
  + */
  +String getSystemKeyConfig() {
  +return systemKeyConfig;
  +}
  +/**
  + * @return Returns the defaultDateFormatConfig.
  + */
  +String getDefaultDateFormatConfig() {
  +return defaultDateFormatConfig;
  +}
  +/**
  + * @return Returns the recentDateFormatConfig.
  + */
  +String getRecentDateFormatConfig() {
  +return recentDateFormatConfig;
  +}
  +/**
  + * @return Returns the serverLanguageCodeConfig.
  + */
  +String getServerLanguageCodeConfig() {
  +return serverLanguageCodeConfig;
  +}
  +/**
  + * @return Returns the serverTimeZoneConfig.
  + */
  +String getServerTimeZoneConfig() {
  +return serverTimeZoneConfig;
  +}
  +/**
  + * @return Returns the shortMonthNamesConfig.
  + */
  +String getShortMonthNamesConfig() {
  +return shortMonthNamesConfig;
  +}
  +/**
* Checks to see that all required parameters are set.
*
* @throws BuildException if the configuration is not valid.
*/
  -protected void checkConfiguration() throws BuildException {
  +protected void checkAttributes() throws BuildException {
   if (server == null) {
   throw new BuildException("server attribute must be set!");
   }
  @@ -1352,6 +1387,15 @@
   throw new BuildException("chmod attribute must be set for chmod "
+ "action!");
   }
  +
  +if (this.isConfigurationSet) {
  +try {
  +Class.forName("org.apache.commons.net.ftp.FTPClientConfig");
  +} catch (ClassNotFoundException e) {
  +throw new BuildException(
  + "commons-net.jar >= 1.4.0 is required for at least one of 
the attributes specified.");
  +}
  +}
   }
   
   
  @@ -2025,40 +2069,7 @@
   
   private void configure(FTPClient ftp) {
   if (this.isConfigurationSet) {
  -FTPClientConfig config;
  -if (this.systemKeyConfig != null) {
  -config = new FTPClientConfig(this.systemKeyConfig);
  -log("custom config: system key = " 
  -+ this.systemKeyConfig, Project.MSG_VERBOSE);
  -} else {
  -config = new FTPClientConfig();
  -}
  -if (this.defaultDateFormatConfig != null) {
  -config.setDefaultDateFormatStr(this.defaultDateFormatConfig);
  -log("custom config: default date format = " 
  -+ this.defaultDateFormatConfig, Project.MSG_VERBOSE);
  -}
  -if (this.recentDateFormatConfig != null) {
  -config.setRecentDateFormatStr(this.recentDateFormatConfig);
  -log("custom config: recent date format = " 
  -+ this.recentDateFormatConfig, Project.MSG_VERBOSE);
  -}
  -if (this.serverLanguageCodeConfig != null) {
  -config.setServerLanguageCode(this.serverLanguageCodeConfig);
  -log("custom config: server language code = " 
  -+ this.serverLanguageCodeConfig, 
Project.MSG_VERBOSE);
  -}
  -if (this.serverTimeZoneConfig != null) {
  -config.setServerTimeZoneId(this.serverTimeZoneConfig);
  -log("custom config: server time zone ID = " 
  -+ this.serverTimeZoneConfig, Project.MSG_VERBOSE);
  -}
  -if (this.shortMonthNamesCo

Re: [Bug 28444] - Import: Target Handling Bug

[Stefan Bodewig]

On Fri, 13 May 2005, Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote:
> Stefan Bodewig wrote:
>> On Thu, 12 May 2005, Dominique Devienne <[EMAIL PROTECTED]>
>> wrote:
> ...
>>>And targets from different imported build files that conflict
>>>(multiple inheritance) should raise an error unless explicitly
>>>imported "as" given by the importer (not the name of the imported
>>>project as is the case now).
>> Can't we have this as an addition anyway?
> 
> Why?

To give the importer control over the prefix and make it a bit more
independent from the author of the imported file.  I may even want to
import to files coming from two different authors but having the same
project name.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 28444] - Import: Target Handling Bug

[Stefan Bodewig]

On Fri, 13 May 2005, Phil Weighill Smith
<[EMAIL PROTECTED]> wrote:
> On Fri, 2005-05-13 at 09:00 +0200, Stefan Bodewig wrote:
> 
>> > But say the importER explicitly depends on bar.foo .  Isn't this
>> > still going to pollute the log in the opposite way my
>> > implementation would? :) i.e.
>> > 
>> > [foo]:
>> > 
>> > [bar.foo]:
>> 
>> Yes.  But this is less likely than having the importer depend on
>> "foo" IMHO.  So in the normal case everything would look the same
>> as today and in border cases we'll get an additional empty target.
> 
> If I understand what you're saying correctly, you don't expect
> importer build scripts to depend explicitly on the renamed imported
> targets.

No.  I fully expect importers to do so now.  And if they do they must
have overridden the target themselves, so what Matt descibes doesn't
happen.

Let's take your example and add a target.

> I'd disagree: we commonly "augment" the standard targets like this:
> 
> standard.xml:
> 
> 
> ...
  
> 
> 
> build.xml:
> 
> 
> 
> 
> ...
> 

Today your build.xml can't use a target that depends on
"standard.new-target" as this target doesn't exist.

Peter's approach would create a copy of "new-target" with the name
"standard.new-target".

Matt's approach would implicitly add a new target

  

to build.xml (which also renames the "new-target" in standard.xml to
"standard.new-target").  Now if you run

$ ant new-target

the output will be

,
| standard.new-target:
| 
| new-target:
`

and you see that new-target has been imported from standard.

My approach would adds

  

to build.xml.  "ant new-target" still looks the same as it would if we
don't add a target at all.  But now if you use

$ ant standard.new-target

the output will be

,
| new-target:
| 
| standard.new-target:
`

So in either case you get to see an implementation detail - the empty
target that either Matt or I wanted to introduce.  I simply claimed
that Matt's case was more likely to happen than mine since you can't
depend on "standard.new-target" or invoke "ant standard.new-target" at
all today.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 28444] - Import: Target Handling Bug

[Stefan Bodewig]

On Fri, 13 May 2005, Steve Loughran <[EMAIL PROTECTED]> wrote:
> Phil Weighill-Smith wrote:
>> I missed the beginning of this thread but just want to say that I
>> personally think that import is the best feature in Ant today
>> (apart from Ant's being in the first place, that is)!
> 
> I find it hard to work with in a big project.
> 
> problems
> -risk of adding a new target in an imported build file conflicting
> with one in the importer (i.e. lack of private scope)

Does that really happen for you?

The workaround is to use ugly, likely to be unique target names - or
address the enhancement request this discussion came from and depend
on "imported.foo" for your newly introduced meant-to-be-private target
"foo".

> -when you override a target, you dont get access to its
> dependents. Workaround: many pseudo-targets that only model
> dependencies.

When you completely want to replace a target that is, true.

Another related problem I have is that you can't add something to the
beginning of a target easily.  You can add someting to the end of
"foo" by writing your own "foo" that depends on "imported.foo", but if
you want to add something at the start your imported build file has to
be designed for it.  Which means pseudo-targets that are used as
interception points only.

> -once you have sub-projects importing ../../common.xml, they are no
> longer self contained, which makes it harder to work with outside
> the existing build tree.

Once we can import URLs, you can have a solution for this, at least
for "network connected" development.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 28444] - Import: Target Handling Bug

[Nicola Ken Barozzi]

Steve Loughran wrote:
Phil Weighill-Smith wrote:
I missed the beginning of this thread but just want to say that I 
personally think that import is the best feature in Ant today (apart 
from Ant's being in the first place, that is)!
I find it hard to work with in a big project.
problems
-risk of adding a new target in an imported build file conflicting with 
one in the importer (i.e. lack of private scope)
>
-when you override a target, you dont get access to its dependents. 
Workaround: many pseudo-targets that only model dependencies.
Could you please explain more? TIA
-once you have sub-projects importing ../../common.xml, they are no 
longer self contained, which makes it harder to work with outside the 
existing build tree.

I dont see any good solution for the latter.
The first and the last "problems" are in fact worksforme, as the import 
task is *intended* to pollute the project files that use it to be able 
to work as needed.

In most cases, one would want to use ,  or  
instead of importing buildfiles with s, which should be used 
only to reuse and "extend" a base buildfile.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 28444] - Import: Target Handling Bug

[Steve Loughran]

Phil Weighill-Smith wrote:
I missed the beginning of this thread but just want to say that I personally think that import is the best feature in Ant today (apart from Ant's being in the first place, that is)!
I find it hard to work with in a big project.
problems
-risk of adding a new target in an imported build file conflicting with 
one in the importer (i.e. lack of private scope)

-when you override a target, you dont get access to its dependents. 
Workaround: many pseudo-targets that only model dependencies.

-once you have sub-projects importing ../../common.xml, they are no 
longer self contained, which makes it harder to work with outside the 
existing build tree.

I dont see any good solution for the latter.
-steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 28444] - Import: Target Handling Bug

[Phil Weighill Smith]

On Fri, 2005-05-13 at 09:00 +0200, Stefan Bodewig wrote:

> > But say the importER explicitly depends on bar.foo .  Isn't this
> > still going to pollute the log in the opposite way my implementation
> > would? :) i.e.
> > 
> > [foo]:
> > 
> > [bar.foo]:
> 
> Yes.  But this is less likely than having the importer depend on "foo"
> IMHO.  So in the normal case everything would look the same as today
> and in border cases we'll get an additional empty target.

If I understand what you're saying correctly, you don't expect importer
build scripts to depend explicitly on the renamed imported targets. I'd
disagree: we commonly "augment" the standard targets like this:

standard.xml:


...


build.xml:




...


I'm not sure if this is what you're discussing or not. What I can say is
that the output of targets and tasks used in our build scripts is very
unclear.

We generally find it difficult tell actually which target caused a given
dependency target to be executed because there are too many "empty"
target names being output (we have various targets that operate "if" and
"unless" variants, but the target name is output even if the condition
fails). In addition, the same "standard" targets are executed multiple
times during our build in different contexts since we have the concept
of "subsystems" within our build:

main-dir/build.xml "ant" executes:

main-dir/subsystem-one/build.xml
main-dir/subsystem-two/build.xml
main-dir/subsystem-.../build.xml

from within targets that have dependencies between each other that
describe subsystem dependencies. Each subsystem build.xml imports the
standard targets and executes them in its context.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs BUnzip2.java GUnzip.java

[bodewig]

bodewig 2005/05/13 01:13:50

  Modified:src/main/org/apache/tools/ant/taskdefs BUnzip2.java
GUnzip.java
  Log:
  Use FileUtils.close()
  
  Revision  ChangesPath
  1.18  +5 -28 ant/src/main/org/apache/tools/ant/taskdefs/BUnzip2.java
  
  Index: BUnzip2.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/BUnzip2.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- BUnzip2.java  25 Jan 2005 16:09:47 -  1.17
  +++ BUnzip2.java  13 May 2005 08:13:50 -  1.18
  @@ -23,6 +23,7 @@
   import java.io.FileOutputStream;
   import java.io.IOException;
   import org.apache.tools.ant.BuildException;
  +import org.apache.tools.ant.util.FileUtils;
   import org.apache.tools.bzip2.CBZip2InputStream;
   
   /**
  @@ -82,34 +83,10 @@
   String msg = "Problem expanding bzip2 " + ioe.getMessage();
   throw new BuildException(msg, ioe, getLocation());
   } finally {
  -if (bis != null) {
  -try {
  -bis.close();
  -} catch (IOException ioex) {
  -// ignore
  -}
  -}
  -if (fis != null) {
  -try {
  -fis.close();
  -} catch (IOException ioex) {
  -// ignore
  -}
  -}
  -if (out != null) {
  -try {
  -out.close();
  -} catch (IOException ioex) {
  -// ignore
  -}
  -}
  -if (zIn != null) {
  -try {
  -zIn.close();
  -} catch (IOException ioex) {
  -// ignore
  -}
  -}
  +FileUtils.close(bis);
  +FileUtils.close(fis);
  +FileUtils.close(out);
  +FileUtils.close(zIn);
   }
   }
   }
  
  
  
  1.26  +4 -21 ant/src/main/org/apache/tools/ant/taskdefs/GUnzip.java
  
  Index: GUnzip.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/GUnzip.java,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- GUnzip.java   11 Mar 2005 15:16:24 -  1.25
  +++ GUnzip.java   13 May 2005 08:13:50 -  1.26
  @@ -22,6 +22,7 @@
   import java.io.IOException;
   import java.util.zip.GZIPInputStream;
   import org.apache.tools.ant.BuildException;
  +import org.apache.tools.ant.util.FileUtils;
   
   /**
* Expands a file that has been compressed with the GZIP
  @@ -70,27 +71,9 @@
   String msg = "Problem expanding gzip " + ioe.getMessage();
   throw new BuildException(msg, ioe, getLocation());
   } finally {
  -if (fis != null) {
  -try {
  -fis.close();
  -} catch (IOException ioex) {
  -//ignore
  -}
  -}
  -if (out != null) {
  -try {
  -out.close();
  -} catch (IOException ioex) {
  -//ignore
  -}
  -}
  -if (zIn != null) {
  -try {
  -zIn.close();
  -} catch (IOException ioex) {
  -//ignore
  -}
  -}
  +FileUtils.close(fis);
  +FileUtils.close(out);
  +FileUtils.close(zIn);
   }
   }
   }
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34893] - unzip task input file remains open after exception

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34893


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-05-13 10:09 ---
The same problem could happen in  as well,  and  seem
to be save.

Fixed in CVS, should be fixed in 1.6.4.  If you can build Ant from sources or
pick up a nightly build of 2005-05-14 or later to confirm it has been fixed,
that would be great.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/zip ZipFile.java

[bodewig]

bodewig 2005/05/13 01:09:35

  Modified:.Tag: ANT_16_BRANCH WHATSNEW
   src/main/org/apache/tools/ant/taskdefs Tag: ANT_16_BRANCH
Untar.java
   src/main/org/apache/tools/zip Tag: ANT_16_BRANCH
ZipFile.java
  Log:
  merge
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.503.2.226 +3 -0  ant/WHATSNEW
  
  Index: WHATSNEW
  ===
  RCS file: /home/cvs/ant/WHATSNEW,v
  retrieving revision 1.503.2.225
  retrieving revision 1.503.2.226
  diff -u -r1.503.2.225 -r1.503.2.226
  --- WHATSNEW  11 May 2005 19:37:30 -  1.503.2.225
  +++ WHATSNEW  13 May 2005 08:09:35 -  1.503.2.226
  @@ -21,6 +21,9 @@
   * Granularity attribute for  task was undocumented.
 Bugzilla report 34871.
   
  +*  and  could leave file handles open on invalid
  +  archives.  Bugzilla report 34893.
  +
   Other changes:
   --
   
  
  
  
  No   revision
  No   revision
  1.37.2.6  +9 -3  ant/src/main/org/apache/tools/ant/taskdefs/Untar.java
  
  Index: Untar.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Untar.java,v
  retrieving revision 1.37.2.5
  retrieving revision 1.37.2.6
  diff -u -r1.37.2.5 -r1.37.2.6
  --- Untar.java6 Jan 2005 17:50:46 -   1.37.2.5
  +++ Untar.java13 May 2005 08:09:35 -  1.37.2.6
  @@ -88,13 +88,13 @@
* @see Expand#expandFile(FileUtils, File, File)
*/
   protected void expandFile(FileUtils fileUtils, File srcF, File dir) {
  +FileInputStream fis = null;
   TarInputStream tis = null;
   try {
   log("Expanding: " + srcF + " into " + dir, Project.MSG_INFO);
  +fis = new FileInputStream(srcF);
   tis = new TarInputStream(
  -compression.decompress(srcF,
  -new BufferedInputStream(
  -new FileInputStream(srcF;
  +compression.decompress(srcF, new BufferedInputStream(fis)));
   TarEntry te = null;
   
   while ((te = tis.getNextEntry()) != null) {
  @@ -113,6 +113,12 @@
   } catch (IOException e) {
   // ignore
   }
  +} else if (fis != null) {
  +try {
  +fis.close();
  +} catch (IOException e) {
  +// ignore
  +}
   }
   }
   }
  
  
  
  No   revision
  No   revision
  1.8.2.7   +11 -2 ant/src/main/org/apache/tools/zip/ZipFile.java
  
  Index: ZipFile.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/zip/ZipFile.java,v
  retrieving revision 1.8.2.6
  retrieving revision 1.8.2.7
  diff -u -r1.8.2.6 -r1.8.2.7
  --- ZipFile.java  9 Mar 2005 18:56:27 -   1.8.2.6
  +++ ZipFile.java  13 May 2005 08:09:35 -  1.8.2.7
  @@ -138,8 +138,17 @@
   public ZipFile(File f, String encoding) throws IOException {
   this.encoding = encoding;
   archive = new RandomAccessFile(f, "r");
  -populateFromCentralDirectory();
  -resolveLocalFileHeaderData();
  +try {
  +populateFromCentralDirectory();
  +resolveLocalFileHeaderData();
  +} catch (IOException e) {
  +try {
  +archive.close();
  +} catch (IOException e2) {
  +// swallow, throw the original exception instead
  +}
  +throw e;
  +}
   }
   
   /**
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/zip ZipFile.java

[bodewig]

bodewig 2005/05/13 01:09:22

  Modified:.WHATSNEW
   src/main/org/apache/tools/ant/taskdefs Untar.java
   src/main/org/apache/tools/zip ZipFile.java
  Log:
   and  could leave streams open.  PR 34893
  
  Revision  ChangesPath
  1.820 +3 -0  ant/WHATSNEW
  
  Index: WHATSNEW
  ===
  RCS file: /home/cvs/ant/WHATSNEW,v
  retrieving revision 1.819
  retrieving revision 1.820
  diff -u -r1.819 -r1.820
  --- WHATSNEW  11 May 2005 19:37:13 -  1.819
  +++ WHATSNEW  13 May 2005 08:09:22 -  1.820
  @@ -213,6 +213,9 @@
   * Granularity attribute for  task was undocumented.
 Bugzilla report 34871.
   
  +*  and  could leave file handles open on invalid
  +  archives.  Bugzilla report 34893.
  +
   Other changes:
   --
   
  
  
  
  1.46  +7 -3  ant/src/main/org/apache/tools/ant/taskdefs/Untar.java
  
  Index: Untar.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Untar.java,v
  retrieving revision 1.45
  retrieving revision 1.46
  diff -u -r1.45 -r1.46
  --- Untar.java6 Jan 2005 17:50:29 -   1.45
  +++ Untar.java13 May 2005 08:09:22 -  1.46
  @@ -90,13 +90,13 @@
* @see Expand#expandFile(FileUtils, File, File)
*/
   protected void expandFile(FileUtils fileUtils, File srcF, File dir) {
  +FileInputStream fis = null;
   TarInputStream tis = null;
   try {
   log("Expanding: " + srcF + " into " + dir, Project.MSG_INFO);
  +fis = new FileInputStream(srcF);
   tis = new TarInputStream(
  -compression.decompress(srcF,
  -new BufferedInputStream(
  -new FileInputStream(srcF;
  +compression.decompress(srcF, new BufferedInputStream(fis)));
   TarEntry te = null;
   FileNameMapper mapper = getMapper();
   while ((te = tis.getNextEntry()) != null) {
  @@ -111,6 +111,10 @@
ioe, getLocation());
   } finally {
   FileUtils.close(tis);
  +if (tis == null) {
  +FileUtils.close(fis);
  +}
  +
   }
   }
   
  
  
  
  1.19  +11 -2 ant/src/main/org/apache/tools/zip/ZipFile.java
  
  Index: ZipFile.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/zip/ZipFile.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- ZipFile.java  9 Mar 2005 00:20:39 -   1.18
  +++ ZipFile.java  13 May 2005 08:09:22 -  1.19
  @@ -138,8 +138,17 @@
   public ZipFile(File f, String encoding) throws IOException {
   this.encoding = encoding;
   archive = new RandomAccessFile(f, "r");
  -populateFromCentralDirectory();
  -resolveLocalFileHeaderData();
  +try {
  +populateFromCentralDirectory();
  +resolveLocalFileHeaderData();
  +} catch (IOException e) {
  +try {
  +archive.close();
  +} catch (IOException e2) {
  +// swallow, throw the original exception instead
  +}
  +throw e;
  +}
   }
   
   /**
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34893] - unzip task input file remains open after exception

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34893


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||dev@ant.apache.org
 AssignedTo|dev@ant.apache.org  |[EMAIL PROTECTED]
   Target Milestone|--- |1.6.4
Version|unspecified |1.6.3




--- Additional Comments From [EMAIL PROTECTED]  2005-05-13 09:10 ---
I could have been staring at the code for ages without realizing that the
constructor was throwing the exception.  Thanks!

A stack-trace would have been helpful.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
You are on the CC list for the bug, or are watching someone who is.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/docs/manual install.html

[Stefan Bodewig]

On Thu, 12 May 2005, Steve Cohen <[EMAIL PROTECTED]> wrote:

> I don't know, though, guys.  What do you think?  Is it really worth
> it to avoid making the users upgrade?

For me it depends on when you wanted to see the new task.

If you wanted to include it in 1.6.4 (which is unlikely to happen
anyway, given Steve's and Matt's comments) then you wouldn't get a +1
from me if it forced people to upgrade commons-net.  This is just too
fresh IMHO.

If you are shooting for 1.7, having the code depend on commons-net
1.4.x is fine with me.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34826] - ORA-00600 running SQLExec w/ keepformat="true"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34826





--- Additional Comments From [EMAIL PROTECTED]  2005-05-13 09:03 ---
Sounds OK.

Maybe a tailfilter would work for you as a workaround?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 28444] - Import: Target Handling Bug

[Stefan Bodewig]

On Thu, 12 May 2005, Matt Benson <[EMAIL PROTECTED]> wrote:

> You confused me with the "later."

I wasn't sure how the target overriding was implemented so wanted to
be save.

> Our local targets are known before we actually execute a top-level
> (target "") import, right?

Probably.  If you say so it will be correct 8-)

> So what I take away from the above is that when there is only one
> "foo", the real work lives in "foo" while "bar.foo" depends on "foo"
> (my idea turned around).

Yes.

> But say the importER explicitly depends on bar.foo .  Isn't this
> still going to pollute the log in the opposite way my implementation
> would? :) i.e.
> 
> [foo]:
> 
> [bar.foo]:

Yes.  But this is less likely than having the importer depend on "foo"
IMHO.  So in the normal case everything would look the same as today
and in border cases we'll get an additional empty target.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]