Re: can I change junit runner main class

[Mariano Benitez]

another option would be to let people extend CommandLineJava and 
overwrite the method getCommandLine() to change the arguments, so I can 
customize my command line while you maintain the contract of JUnitRunner.

I think I will move in this direction since not only I need to change 
the main class, but also make the classpath an argument of the main 
class and not a java argument, for example:

java -classpath whatever.jar JUnitTestRunner blah
to
java -jar /path/myJar.jar -classpath whatever.jar JUnitTestRunner blah
MAriano
Mariano Benitez wrote:

I assume that your class understands all the command line arguments
Ant's testrunner uses and passes them along.  How would your class
deal with new arguments we add?
 

My class is just a bootstrap that do some classloading stuff regarding 
my application and then invokes the main class (JUnitRunner) with the 
parameteres it received in the first place.

The main problem with opening up access to the test runner class is
just that.  As soon as we do it, we run the risk of breaking other
people's builds when we change the protocol between the task and the
test runner.  There is no danger now, as we always know the main class
that gets invoked.
 

I agree 100% with you on this, it is just that I need to take control 
"before" the main class is executed, actually I build a classloader 
where the main class (Runner) is loaded and executed.

I know this is a quite unique situation but I just wanted to expose my 
case to see if it is so unique that is ok that I handle it myself 
only. I have patched JUnitTask to specify another main class that I 
built that ultimately call JUnitRunner as usual.

1) leave  and have "launcher"
script change the command line
  

Ugly but portable accross Ant versions.
 

I have scripts since they always have problems with different OS, etc, 
that was the first option, but I end up having 3 bash processes 
wrapping java.

2) patch junit to allow me to put a boot class
3) extend junit (the problem is that JUnitTask.executeAsForked and
commandline are private, so I should patch the task anyway)
  

what you can do to support extension of JUnit is to leave a hook to 
alter the commandline, this way I can do whatever I need directly 
before invoking the runner. You could just leave a method protected so 
I can extend it and alter the command line in a custom task.

Thanks a lot for the attention,
MAriano
-
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: Ant 2.0

[Steve Loughran]

Dale Anson wrote:
I've also ran into this problem, which prompted the  task that 
is now in ant-contrib as a solution. It works a lot like Java's assert 
in that it can be turned on or off either through a command line 
parameter or by a property. It is a task, so does require build file 
modification, but it is useful for making sure that a property is set or 
set to the right value at a particular spot in the build.

yes, assertions. I see.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Any feedback on the shell script changes?

[Antoine Lévy-Lambert]

Stefan Bodewig wrote:
Hi,
I'd like to merge the modifications I made to the Unix wrapper script
and the Launcher to the 1.6. branch so that it gets released in
1.6.1.  Has anybody found time to try the changed script on Cygwin or
even AIX?
 

I have tested the script under cygwin.
I only have one small modification, which is attached and that I 
reproduce inline below.

The script is working for me with :
$ANT_HOME set to a dir with space
and also
$ANT_HOME set to a dir with space and one lib directory containing an 
embedded space.

I have also done the test of Matt Benson concerning setting HOME in 
cygwin to /cygdrive/c.

I have also included a fix for this special case in the patch, and also 
for 3 other variables possibly ending with a backslash.

Cheers,
Antoine

Index: src/script/ant
===
RCS file: /home/cvs/ant/src/script/ant,v
retrieving revision 1.44
diff -u -r1.44 ant
--- src/script/ant9 Feb 2004 21:05:40 -1.44
+++ src/script/ant10 Feb 2004 22:10:47 -
@@ -27,11 +27,11 @@
use_jikes_default=true
  elif [ "$arg" = "--execdebug" ] ; then
ant_exec_debug=true
-  elif [ "$arg" = "--h" -o "$arg" = "--help" ] ; then
+  elif [ my"$arg" = my"--h"  -o my"$arg" = my"--help"  ] ; then
show_help=true
ant_exec_args="$ant_exec_args -h"
  else
-if [ "$arg" = "-h" -o "$arg" = "-help" ] ; then
+if [  my"$arg" = my"-h"  -o  my"$arg" = my"-help" ] ; then
  show_help=true
fi
ant_exec_args="$ant_exec_args \"$arg\""
@@ -243,7 +243,29 @@
  echo ' launch script'
  echo '  '
fi
-
+# add a second backslash to variables terminated by a backslash under 
cygwin
+if $cygwin; then
+  case "$CYGHOME" in
+*\\ )
+CYGHOME="$CYGHOME\\"
+;;
+  esac
+  case "$JIKESPATH" in
+*\\ )
+JIKESPATH="$JIKESPATH\\"
+;;
+  esac
+  case "$LOCALCLASSPATH" in
+*\\ )
+LOCALCLASSPATH="LOCALCLASSPATH\\"
+;;
+  esac
+  case "$CLASSPATH" in
+*\\ )
+CLASSPATH="$CLASSPATH\\"
+;;
+  esac
+fi
# Execute ant using eval/exec to preserve spaces in paths,
# java options, and ant args
ant_sys_opts=

Index: src/script/ant
===
RCS file: /home/cvs/ant/src/script/ant,v
retrieving revision 1.44
diff -u -r1.44 ant
--- src/script/ant  9 Feb 2004 21:05:40 -   1.44
+++ src/script/ant  10 Feb 2004 22:10:47 -
@@ -27,11 +27,11 @@
 use_jikes_default=true
   elif [ "$arg" = "--execdebug" ] ; then
 ant_exec_debug=true
-  elif [ "$arg" = "--h" -o "$arg" = "--help" ] ; then
+  elif [ my"$arg" = my"--h"  -o my"$arg" = my"--help"  ] ; then
 show_help=true
 ant_exec_args="$ant_exec_args -h"
   else
-if [ "$arg" = "-h" -o "$arg" = "-help" ] ; then
+if [  my"$arg" = my"-h"  -o  my"$arg" = my"-help" ] ; then
   show_help=true
 fi
 ant_exec_args="$ant_exec_args \"$arg\""
@@ -243,7 +243,29 @@
   echo ' launch script'
   echo '  '
 fi
-
+# add a second backslash to variables terminated by a backslash under cygwin
+if $cygwin; then
+  case "$CYGHOME" in
+*\\ )
+CYGHOME="$CYGHOME\\"
+;;
+  esac
+  case "$JIKESPATH" in
+*\\ )
+JIKESPATH="$JIKESPATH\\"
+;;
+  esac
+  case "$LOCALCLASSPATH" in
+*\\ )
+LOCALCLASSPATH="LOCALCLASSPATH\\"
+;;
+  esac
+  case "$CLASSPATH" in
+*\\ )
+CLASSPATH="$CLASSPATH\\"
+;;
+  esac
+fi
 # Execute ant using eval/exec to preserve spaces in paths,
 # java options, and ant args
 ant_sys_opts=

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

Re: Ant 2.0

[Dale Anson]

I've also ran into this problem, which prompted the  task that 
is now in ant-contrib as a solution. It works a lot like Java's assert 
in that it can be turned on or off either through a command line 
parameter or by a property. It is a task, so does require build file 
modification, but it is useful for making sure that a property is set or 
set to the right value at a particular spot in the build.

Dale
Stefan Bodewig wrote:
On Sun, 08 Feb 2004, Steve Loughran <[EMAIL PROTECTED]> wrote:

One thing that was voted on (positively, I recall), way  way back in
time, was for Ant2.0 to fail on undefined properties.

Although I've never looked into it, can't you already have it with a
custom PropertyHelper?  If you can ensure that your custom property
helper is the last one that gets called - and that it never gets
called for know properties - you should be there.
Provide this property helper and maybe add a new command line switch
as syntactic sugar, done.

3. But there would be a non-throwing expansion method for code that
explicitly wanted to not fail on missing strings in their .

The PropertyHelper could deal with it.
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]

DO NOT REPLY [Bug 26837] New: - xml parser fails with content not allowed in prolog

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=26837

xml parser fails with content not allowed in prolog

   Summary: xml parser fails with content not allowed in prolog
   Product: Ant
   Version: 1.6.0
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Build Process
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I am new to Ant.  I installed on my pc as described in the manual.

Using the tutorial build.xml file I run ant with the -debug option.

the error I get is 1:1 content is not allowed in prolog.

I tried removing the xml parsers because I am using Java 1.4, but I get a "no 
root node" error.

I can't try anything until else until I get past this.

It seems like there is some kind of configuration error on my part.

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

Re: Any feedback on the shell script changes?

[Matt Benson]

--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> 1.6.1.  Has anybody found time to try the changed
> script on Cygwin or
> even AIX?

More info:  I found the bug because I have HOME set to
/cygdrive/d aka D:\ .  When constructing
ant_exec_command in the ant script, escaped
double-quotes are added.  When I changed these to
single-quotes around $CYGHOME it fixed my problem. 
But just for kicks I set CLASSPATH to end with a
trailing backslash (I normally keep it unset) and got
the same problem.  The trailing backslash is, of
course, escaping the following double-quote and making
the command line appear to contain an unterminated
quoted string.  Even better, combine the two and the
second cancels out the first, but loses the launcher
classname in the cygwin.user.home value.  :)  Does the
use of eval here have to do with that environment
variable/rpm (IIRC) stuff that was floating around
awhile back?  Is there another way to make sure
everything has been thoroughly evaluated so we can
pass args single-quoted?

-Matt


__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

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

DO NOT REPLY [Bug 26286] - XmlProperty: empty element semantic problems

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=26286

XmlProperty: empty element semantic problems

[EMAIL PROTECTED] changed:

   What|Removed |Added

Version|1.5.4   |1.6.1beta1



--- Additional Comments From [EMAIL PROTECTED]  2004-02-10 18:14 ---
Confirmed problem still exists in 1.6.1beta1

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

Re: Task for the new Pack200 format

[Steve Loughran]

Stefan Bodewig wrote:
Hi,
Java 1.5 comes with support for a new archive format Pack200[1] which
basically works by using a special compression algorithm that is very
effective on Java class files.  The way to create such an archive is
to create a plain old jar first and then turn ot into a Pack200
archive - "depack200"ing again yields a jar archive.
Sine Java 1.5 comes with a straight forward utility class[2], creating
 and  tasks would be quite simple - and first
enhancement request are predicted to pop up soon 8-)
Do we want to make them core tasks or do we want to farm them out into
an antlib of their own?

Antlib. That way people w/ Ant1.6 will be able to use them, and it shows 
that we think antlibs are the future of addon stuff.

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

Re: can I change junit runner main class

[Mariano Benitez]

I assume that your class understands all the command line arguments
Ant's testrunner uses and passes them along.  How would your class
deal with new arguments we add?
 

My class is just a bootstrap that do some classloading stuff regarding 
my application and then invokes the main class (JUnitRunner) with the 
parameteres it received in the first place.

The main problem with opening up access to the test runner class is
just that.  As soon as we do it, we run the risk of breaking other
people's builds when we change the protocol between the task and the
test runner.  There is no danger now, as we always know the main class
that gets invoked.
 

I agree 100% with you on this, it is just that I need to take control 
"before" the main class is executed, actually I build a classloader 
where the main class (Runner) is loaded and executed.

I know this is a quite unique situation but I just wanted to expose my 
case to see if it is so unique that is ok that I handle it myself only. 
I have patched JUnitTask to specify another main class that I built that 
ultimately call JUnitRunner as usual.

1) leave  and have "launcher"
script change the command line
   

Ugly but portable accross Ant versions.
 

I have scripts since they always have problems with different OS, etc, 
that was the first option, but I end up having 3 bash processes wrapping 
java.

2) patch junit to allow me to put a boot class
3) extend junit (the problem is that JUnitTask.executeAsForked and
commandline are private, so I should patch the task anyway)
   

what you can do to support extension of JUnit is to leave a hook to 
alter the commandline, this way I can do whatever I need directly before 
invoking the runner. You could just leave a method protected so I can 
extend it and alter the command line in a custom task.

Thanks a lot for the attention,
MAriano
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Any feedback on the shell script changes?

[Matt Benson]

--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I'd like to merge the modifications I made to the
> Unix wrapper script
> and the Launcher to the 1.6. branch so that it gets
> released in
> 1.6.1.  Has anybody found time to try the changed
> script on Cygwin or
> even AIX?

I'm getting "unterminated quoted string" errors on
cygwin... looking into it now.

-Matt

__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

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

Re: multi-result s

[Peter Reilly]

Jose Alberto Fernandez wrote:
I am all with you on the goal, my only point is that rather than
creating yet another way for mappers, we should do best by starting
working on 1.7's features so we try to converge to a unified model.
It would mean that mappers can be in their own antlib library,
use their owm NameSpace and all the other goodies of the model.
 

I believe that is the aim for 1.7 with the
add(Interface)
methods.
 

which are these?
   

This are new instrospection methods so that Conditions, mappers, etc
can be added and made available to all tasks automagically.
They are suppose to be part of 1.7.
 

This is want the patch does.
The patch makes the mapper class to be a container of
filenamemapper objects in the same way that conditionbase
is a container of conditions.
so:

becomes:

  

The two forms are allowed and are equivalent.
The second from allows more filename mappers to
be added so:

  
  

will map a/b/P.java to ${destdir}/a/b/P.xml
and a/b/P.xml to ${destdir}/a/b/P.meta.xml
The filenamemappers are found by using the add(FileNameMapper) method
in the mapper class so one can add new mappers easily.

 package my.mappers;
 import org.apache.tools.ant.util.FileNameMapper;
 public class upcasemapper implements FileNameMapper {
 public void setFrom(String ignore) {}
 public void setTo(String ignore) {}
 public String[] mapFileName(String filename) {
 return new String[] {filename.toUpperCase()};
 }
 }

The filename mappers can be combined as a chain so that the output of the
first map is the input to the second map.

  
  
  

would map a/b/P.java to ${destdir}/A/B/P.xml
Normal ant reflection is used on the filename mapper classes, so
the mapper classes may have extra attributes or nested elements.
For example the attribute "casesensitive" default yes could be added
to the globmapper:

   

would map a/b/t.META.java to ${destdir}/a/b/t.xml
This patch would be for ant 1.7 and not ant 1.6. It is expected that
during the construction of ant 1.7, roles or something similar would be
added to allow container specific nameing of typedef'ed nested elements.
In the meantime, the patch simply defines the current filename mappers as
normal global typedefs.
Peter

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

RE: multi-result s

[Matt Benson]

--- Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:
> rather than creating yet another way for mappers,
> we should do best by starting working on 1.7's
> features so we try to converge to a unified model.

Are you meaning that ing FileNameMappers is
but a small part of something that needs to be done on
a grand scale for 1.7?  Fine by me.

> It would mean that mappers can be in their own
> antlib library,
> use their owm NameSpace and all the other goodies of
> the model.
 
Are you talking about custom mappers?  Sticking core
mappers into a separate namespace feels kind of funny
to me.  Not exactly wrong, but my BC sense is
tingling... I'm sure that can't be the whole story.

> > > I believe that is the aim for 1.7 with the
> > > add(Interface)
> > > methods.
> This are new instrospection methods so that
> Conditions, mappers, etc
> can be added and made available to all tasks
> automagically.
> They are suppose to be part of 1.7.

Do these methods exist in some form in the current
codebase or are they still in a planning phase?  Are
you touching on the "role" concept here?  I've been
wanting to know more about that.

-Matt

__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

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

RE: can I change junit runner main class

[Dominique Devienne]

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> On Mon, 09 Feb 2004, Mariano Benitez <[EMAIL PROTECTED]> wrote:
> > The problem is that I cannot simulate this using JUnit with
> > fork, because I cannot change the main class and use mine
> > instead.
> 
> I assume that your class understands all the command line arguments
> Ant's testrunner uses and passes them along.  How would your class
> deal with new arguments we add?
> 
> The main problem with opening up access to the test runner class is
> just that.  As soon as we do it, we run the risk of breaking other
> people's builds when we change the protocol between the task and the
> test runner.  There is no danger now, as we always know the main class
> that gets invoked.

The solution would be to make the Ant test runner public and extensible, so
that people that need to extend it, for example to run all the tests in a
single forked VM instead of the super slow forking for every test current
mode, can do so. The current approach is too much a closed-system.

BTW, the patch submitted against Ant 1.5.x to allow forking once was never
incorporated. When I tested this patch, the  tasks is 7x faster!
Starting up a new VM for every single tests just ain't efficient enough.

--DD

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

Re: Task for the new Pack200 format

[Matt Benson]

(butchered for context)
--- "Alexey N. Solofnenko" <[EMAIL PROTECTED]>
wrote:
> Stefan Bodewig wrote:
> >So far I haven't found a technical spec for the
> format so I don't know
> >whether we can implement it.
> 
> It is there:
>
http://jcp.org/aboutJava/communityprocess/review/jsr200/index.html

> Stefan Bodewig wrote:
> >A JDK 1.5 only
> implementation would be
> >trivial.

Based on the information in William Pugh's
"Compressing Java Class Files" article, reinventing
the wheel in this case sounds distinctly non-trivial. 
At the same time, I can't imagine why Pack200
wouldn't/couldn't be made available independent of
Tiger--other than the reasons alleged by Costin.  ;)

-Matt

__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

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

RE: multi-result s

[Jose Alberto Fernandez]

> From: Matt Benson [mailto:[EMAIL PROTECTED] 
> 
> --- Jose Alberto Fernandez <[EMAIL PROTECTED]>
> wrote:
> > I think we are now in the new world of ANT 1.6
> > (the wold of namespaces and antlibs).
> > We should stride to focus our efforts so that
> > all our extension points (of all sorts) follow
> > the antlibs/typedef approach and move away from
> > having property files with magic names defining
> > special types.
> > 
> I'm not sure what alternative you're suggesting.  The 
> properties files themselves are used by .  I guess 
> this hasn't been implemented yet, but I seem to recall a 
> message to the effect that the core tasks could/should/would? 
> be defined by an  for the default namespace, which 
> would consist of  resource="o.a.t.a.taskdefs/defaults.properties" /> and 
>  /> until such time as someone decided to expand it
> into individual <*def> elements, if ever.  I don't
> feel that the properties files themselves are all that 
> important; they are just the simplest (for now) means of 
> defining the core types.  The point here is that 
> , , et al., having 
> been d, would be available as specific elements in 
> addition to the BC .
> 

I am all with you on the goal, my only point is that rather than
creating yet another way for mappers, we should do best by starting
working on 1.7's features so we try to converge to a unified model.
It would mean that mappers can be in their own antlib library,
use their owm NameSpace and all the other goodies of the model.

> > I believe that is the aim for 1.7 with the
> > add(Interface)
> > methods.
> > 
> which are these?
> 

This are new instrospection methods so that Conditions, mappers, etc
can be added and made available to all tasks automagically.
They are suppose to be part of 1.7.

Jose Alberto

> -Matt
> 
> __
> Do you Yahoo!?
> Yahoo! Finance: Get your refund fast by filing online. 
http://taxes.yahoo.com/filing.html

-
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: Task for the new Pack200 format

[Alexey N. Solofnenko]

It is there:
http://jcp.org/aboutJava/communityprocess/review/jsr200/index.html
- Alexey.
Stefan Bodewig wrote:
On Tue, 10 Feb 2004, Costin Manolache <[EMAIL PROTECTED]> wrote:
 

"core tasks" would be the right solution if it could be implemented
using JDK1.3
   

1.2, you mean 8-)
So far I haven't found a technical spec for the format so I don't know
whether we can implement it.  A JDK 1.5 only implementation would be
trivial.
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]

Re: Task for the new Pack200 format

[Stefan Bodewig]

On Tue, 10 Feb 2004, Costin Manolache <[EMAIL PROTECTED]> wrote:

> "core tasks" would be the right solution if it could be implemented
> using JDK1.3

1.2, you mean 8-)

So far I haven't found a technical spec for the format so I don't know
whether we can implement it.  A JDK 1.5 only implementation would be
trivial.

Stefan

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

DO NOT REPLY [Bug 25674] - delete with followSymlinks=false fails if pointed at non-existant directory

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25674

delete with followSymlinks=false fails if pointed at non-existant directory





--- Additional Comments From [EMAIL PROTECTED]  2004-02-10 16:20 ---
Oops I trusted the error message too much... the error message says it doesn't
exist, but in fact the failure occurs when the directory DOES exist and
followsymlinks="false". Just attached a file that demonstrates this on 

Apache Ant version 1.7alpha compiled on December 22 2003

A little out of date, but probably still relevant.

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

DO NOT REPLY [Bug 25674] - delete with followSymlinks=false fails if pointed at non-existant directory

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25674

delete with followSymlinks=false fails if pointed at non-existant directory





--- Additional Comments From [EMAIL PROTECTED]  2004-02-10 16:17 ---
Created an attachment (id=10297)
build deomonstrating the problem.

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

RE: Task for the new Pack200 format

[Jan . Materne]

> >>Do we want to make them core tasks or do we want to farm 
> them out into
> >>an antlib of their own?
> >>
> > 
> > Because its based only on (new) standard classes I would do that as
> > core tasks. And as an adoption of , so the user doesn´t has to
> > create the JAR bofore "pack200"ing.
> 
> "core tasks" would be the right solution if it could be implemented 
> using JDK1.3 ( or even 1.4 ), or at very least use introspection.
> I'm kind of -1 for conditional compilation ( which would 
> force ant to be 
> built with 1.5 beta ).
> 
> It would be really nice to have pack200 implemented in 1.3, 
> both packer 
> and unpacker/class loader - it would reduce the size of our code and 
> make this cool feature available _now_ and to everyone. I 
> hate when Sun
> bundles features with JDK ( like logging, NIO ) in order to force 
> adoption, hurting the new feature and existing users who 
> can't benefit 
> from them, and eventually the standard itself, since alternative 
> solutions supporting current VMs are more likely to be 
> adopted instead.

We can make an OptionalTask. There´s no difference in the users 
point of view - if he had the needed 3rd party lib. The task is
available without the need of ing it or declaring via
namespace. 


As an antlib maybe we could bundle it with the 3rd party lib. But
if that file format should become the future "jar"-format, then the
task should be part of Ant itself - not an external.


So I see these possibilities:
1) Optional Task and conditional compile, depending on presence of
   JDK 1.5.
2) Core Task and the implementation of the format as a util class
3) AntLib with bundled lib
4) AntLib without bundled lib and autodownload ;-)

I think the first would be the best. Reimplementing the format wouldn´t
be easy enough. And if done, it should go into the Jakarta-Commons. And
then we have an external lib - same as the first ...

I´m not sure whether we can bundle the lib (if it´s available as a 
standalone lib) - depends on the license.

Autodownload ... another topic ...



Jan

Re: Task for the new Pack200 format

[Costin Manolache]

[EMAIL PROTECTED] wrote:
Java 1.5 comes with support for a new archive format Pack200[1] which
basically works by using a special compression algorithm that is very
effective on Java class files.  The way to create such an archive is
to create a plain old jar first and then turn ot into a Pack200
archive - "depack200"ing again yields a jar archive.
Sine Java 1.5 comes with a straight forward utility class[2], creating
 and  tasks would be quite simple - and first
enhancement request are predicted to pop up soon 8-)
Do we want to make them core tasks or do we want to farm them out into
an antlib of their own?
Stefan
Footnotes: 
[1]  http://jcp.org/en/jsr/detail?id=200

[2]  http://java.sun.com/j2se/1.5.0/docs/api/javax/pack/Pack200.html

Because its based only on (new) standard classes I would do that as
core tasks. And as an adoption of , so the user doesn´t has to
create the JAR bofore "pack200"ing.
"core tasks" would be the right solution if it could be implemented 
using JDK1.3 ( or even 1.4 ), or at very least use introspection.
I'm kind of -1 for conditional compilation ( which would force ant to be 
built with 1.5 beta ).

It would be really nice to have pack200 implemented in 1.3, both packer 
and unpacker/class loader - it would reduce the size of our code and 
make this cool feature available _now_ and to everyone. I hate when Sun
bundles features with JDK ( like logging, NIO ) in order to force 
adoption, hurting the new feature and existing users who can't benefit 
from them, and eventually the standard itself, since alternative 
solutions supporting current VMs are more likely to be adopted instead.

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

DO NOT REPLY [Bug 26737] - Directory Scanner failure

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=26737

Directory Scanner failure





--- Additional Comments From [EMAIL PROTECTED]  2004-02-10 15:27 ---


 
 





 
  

release.ProductionImage was read from a "release.properties" file:

release.ProductionImage=2004_01_30_Production

and the developer inadvertently inserted a space at the end of the line so the 
value was "2004_01_30_Production ".

Normaly my build.xml checks all such items for validity, but I forgot to do 
this in this case. The copy task was executed with the above value resulting 
in the exception (the productionImage.dir had a valid value).

This is on "Apache Ant version 1.5.3 compiled on April 9 2003" and java 
version "1.3.1_08", however I checked the current 1.6 code base and it still 
contains the fragment I cited. I can't easily test this build.xml on 1.6 
because it uses some custom tasks of mine that are dependent of 1.5.3.

BTW: Mid-last year I put forward a proposal for adding a mapper to zipfilesets 
and selectors and a contentmapper to zipgroupfilesets (a contentmapper 
transforms names of zip entries as they are transferred from the input zips to 
the target zips). I implemented this as a custom task based on the core zip 
task (hence the incompatibility with anything but 1.5.3). 

I tried to offer this implementation for inclusion, but was totally unablae to 
elicit any response at all (not even go away, don't bother us...). Did I 
transgress etiquette in some way?

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

RE: Task for the new Pack200 format

[Matt Benson]

--- [EMAIL PROTECTED] wrote:
> Because its based only on (new) standard classes I
> would do that as
> core tasks. And as an adoption of , so the user
> doesn´t has to
> create the JAR bofore "pack200"ing.

+1

-Matt

__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

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

RE: multi-result s

[Matt Benson]

--- Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:
> I think we are now in the new world of ANT 1.6
> (the wold of namespaces and antlibs).
> We should stride to focus our efforts so that
> all our extension points (of all sorts) follow
> the antlibs/typedef approach and move away from
> having property files with magic names defining
> special types.
> 
I'm not sure what alternative you're suggesting.  The
properties files themselves are used by .  I
guess this hasn't been implemented yet, but I seem to
recall a message to the effect that the core tasks
could/should/would? be defined by an  for the
default namespace, which would consist of  and
 until such time as someone decided to expand it
into individual <*def> elements, if ever.  I don't
feel that the properties files themselves are all that
important; they are just the simplest (for now) means
of defining the core types.  The point here is that
, , et al.,
having been d, would be available as specific
elements in addition to the BC .

> I believe that is the aim for 1.7 with the
> add(Interface)
> methods.
> 
which are these?

-Matt

__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

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

RE: multi-result s

[Jose Alberto Fernandez]

I think we are now in the new world of ANT 1.6
(the wold of namespaces and antlibs).
We should stride to focus our efforts so that
all our extension points (of all sorts) follow
the antlibs/typedef approach and move away from
having property files with magic names defining
special types.

I believe that is the aim for 1.7 with the add(Interface)
methods.

Jose Alberto

> -Original Message-
> From: Matt Benson [mailto:[EMAIL PROTECTED] 
> Sent: 09 February 2004 23:23
> To: Ant Developers List
> Subject: multi-result s
> 
> 
> Stefan and I talked about doing one of these here:
> 
> http://marc.theaimsgroup.com/?l=ant-user&m=107487826503877&w=2
> 
> Peter and I each produced a different implementation. 
> See
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26364
> for our discussion.  In the end Peter's changes are
> probably more powerful than mine but his specific 
> implementation represents a paradigm shift, hence our 
> decision to start a thread devoted to the issue.
> 
> s have always been specified via a 
> element and either a "type" or "classname" attribute,
> which actually specified an implementation of
> FileNameMapper.  Peter's proposition allows to define
> the implementation type directly in
> types/defaults.properties, then nest these directly
> into the  element.  In this way s
> would/could look a lot more like s and
> s, especially when ref'd.  Another note is
> that adding new core mappers would be a properties
> file (or other typedef) edit rather than a change to
> an EnumeratedAttribute.  Finally, this allows more
> specialized attributes on mappers than just "to" and
> "from".  So... does anyone have a problem with
> changing the recommended usage of s while
> maintaining BC?
> 
> -Matt
> 
> __
> Do you Yahoo!?
> Yahoo! Finance: Get your refund fast by filing online. 
http://taxes.yahoo.com/filing.html

-
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: output redirectors

[Conor MacNeill]

On Tue, 10 Feb 2004 13:47:01 +0100, Stefan Bodewig <[EMAIL PROTECTED]> 
wrote:
Start with the two new ones and enhance ;-) one existing class in HEAD
so we can see where you are going?
Agreed - apply it in bits if you can so people can digest in small lumps 
but it sounds good.

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

Re: output redirectors

[Stefan Bodewig]

On Tue, 10 Feb 2004, Matt Benson <[EMAIL PROTECTED]> wrote:

> Would it make sense here to create a new core FilterReader for
> encoding conversions, and let that be the proscribed means by which
> input/output/error encoding can be overridden for a
> --using the <*filterchain> elements already implemented?
> Seems clean/reusable to me.

To be able to use encodings you have to work on the "raw" byte
streams, not on readers.  You have to set the encoding on
InputStreamReaders or OutputStreamWriters and pass those to the filter
chain.

> I don't know exactly how the entire sandbox paradigm
> is intended to flow, but this enhancement (I hate to
> say "change" :)  ) affects about 4-5 existing classes
> and two (IIRC) new ones, plus the encoding
> FilterReader if we go that route.

Start with the two new ones and enhance ;-) one existing class in HEAD
so we can see where you are going?

Stefan

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

Re: Task for the new Pack200 format

[Antoine Lévy-Lambert]

[EMAIL PROTECTED] wrote:
Java 1.5 comes with support for a new archive format Pack200[1] which
basically works by using a special compression algorithm that is very
effective on Java class files.  The way to create such an archive is
to create a plain old jar first and then turn ot into a Pack200
archive - "depack200"ing again yields a jar archive.
Sine Java 1.5 comes with a straight forward utility class[2], creating
 and  tasks would be quite simple - and first
enhancement request are predicted to pop up soon 8-)
Do we want to make them core tasks or do we want to farm them out into
an antlib of their own?
Stefan
Footnotes: 
[1]  http://jcp.org/en/jsr/detail?id=200

[2]  http://java.sun.com/j2se/1.5.0/docs/api/javax/pack/Pack200.html
   


Because its based only on (new) standard classes I would do that as
core tasks. And as an adoption of , so the user doesn´t has to
create the JAR bofore "pack200"ing.
Jan
 

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

DO NOT REPLY [Bug 26737] - Directory Scanner failure

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=26737

Directory Scanner failure





--- Additional Comments From [EMAIL PROTECTED]  2004-02-10 12:43 ---
So how do you create such a situation where a File instance that is not a valid
directory gets passed to the scanDir method?  Wich task do you use to trigger
the problem?

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

DO NOT REPLY [Bug 26739] - should put all parameters into an external file when requested or automatically

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=26739

 should put all parameters into an external file when requested or 
automatically

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Major   |Normal



--- Additional Comments From [EMAIL PROTECTED]  2004-02-10 12:39 ---
According to
http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/javadoc.html#argumentfile
the @argumentfile must not contain anything but file or package names in JDK 
1.3.

Could you please modify your patch to only use the external file for other
command line arguments if javadoc4 is true?

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

Re: output redirectors

[Matt Benson]

--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> 
> You miss encoding attributes.
> 
Ah--I am by my own admission a little ignorant on
encoding concepts... tunnel vision.  I'll have to work
on that.  Would it make sense here to create a new
core FilterReader for encoding conversions, and let
that be the proscribed means by which
input/output/error encoding can be overridden for a
--using the <*filterchain> elements
already implemented?  Seems clean/reusable to me.

> Depending on the size of the change it may be
> easiest to either commit
> it to HEAD or start a little sandbox for it in the
> proposal/sandbox
> area.
> 
I don't know exactly how the entire sandbox paradigm
is intended to flow, but this enhancement (I hate to
say "change" :)  ) affects about 4-5 existing classes
and two (IIRC) new ones, plus the encoding
FilterReader if we go that route.  These counts do not
include test cases and documentation.

> Stefan
> 
Thanks,
-Matt

__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

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

DO NOT REPLY [Bug 26765] - "-f" option works incorrectly if path includes "../"

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=26765

"-f" option works incorrectly if path includes "../"





--- Additional Comments From [EMAIL PROTECTED]  2004-02-10 12:35 ---
Could you please attach your build file?  Things seem to work for me.

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

DO NOT REPLY [Bug 25674] - delete with followSymlinks=false fails if pointed at non-existant directory

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25674

delete with followSymlinks=false fails if pointed at non-existant directory





--- Additional Comments From [EMAIL PROTECTED]  2004-02-10 12:32 ---
 always fails for me, no matter which value I give to
the followsymlinks attribute - if ${tdir} doesn't exist, that is.

If I set quiet to true in addition, it passes in either case.

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

Re: [Patch] Support for the groovy language with the ant

[Peter Reilly]

Stefan Bodewig wrote:
On Tue, 03 Feb 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
 

This time with the attachment
   

Hmm, why have you changed the script names to remove the angle
brackets?
 

This is due to a bug in the groovy support for BSF. It seems that
a class is made for the name used in the script name (?), at least
that is what the error message seems to imply.
I will make a bug report to groovy, (now that after upgrading firebird 0.7
to firefox 0.8, I can actually login to the jira account...).
Peter
+1 to your patch, BTW.
Stefan
 


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

Any feedback on the shell script changes?

[Stefan Bodewig]

Hi,

I'd like to merge the modifications I made to the Unix wrapper script
and the Launcher to the 1.6. branch so that it gets released in
1.6.1.  Has anybody found time to try the changed script on Cygwin or
even AIX?

Peter, I think that making Ant ignore the additional command line
arguments would be a reasonable alternative and am willing to make
that change.  Does anybody else have any preferences?

Stefan

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

Re: [Patch] Support for the groovy language with the ant

[Stefan Bodewig]

On Tue, 03 Feb 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:

> This time with the attachment

Hmm, why have you changed the script names to remove the angle
brackets?

+1 to your patch, BTW.

Stefan

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

Re: output redirectors

[Stefan Bodewig]

On Mon, 9 Feb 2004, Matt Benson <[EMAIL PROTECTED]> wrote:

> Nested elements supported include:
> , , ,
> , ,
> .  These do what you might expect
> and provide about every possibility I could think of. 
> These are not compatible with the similar attributes.

You miss encoding attributes.

> I am now seeking feedback on the sanity of this
> design.

Sounds interesting.

> I haven't explained every in and out here so please ask if there are
> any questions.

Depending on the size of the change it may be easiest to either commit
it to HEAD or start a little sandbox for it in the proposal/sandbox
area.

Stefan

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

Re: Task for the new Pack200 format

[Stefan Bodewig]

On Tue, 10 Feb 2004, Jan Materne <[EMAIL PROTECTED]> wrote:

> And as an adoption of , so the user doesn´t has to create the
> JAR bofore "pack200"ing.

Yes, sounds useful.  In particular since the Pack200 class deals with
streams, so we could create the initial jar in memory - if it is small
enough, that is.

Stefan

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

RE: Task for the new Pack200 format

[Jan . Materne]

> Java 1.5 comes with support for a new archive format Pack200[1] which
> basically works by using a special compression algorithm that is very
> effective on Java class files.  The way to create such an archive is
> to create a plain old jar first and then turn ot into a Pack200
> archive - "depack200"ing again yields a jar archive.
> 
> Sine Java 1.5 comes with a straight forward utility class[2], creating
>  and  tasks would be quite simple - and first
> enhancement request are predicted to pop up soon 8-)
> 
> Do we want to make them core tasks or do we want to farm them out into
> an antlib of their own?
> 
> Stefan
> 
> Footnotes: 
> [1]  http://jcp.org/en/jsr/detail?id=200
> 
> [2]  http://java.sun.com/j2se/1.5.0/docs/api/javax/pack/Pack200.html
> 


Because its based only on (new) standard classes I would do that as
core tasks. And as an adoption of , so the user doesn´t has to
create the JAR bofore "pack200"ing.

Jan

Task for the new Pack200 format

[Stefan Bodewig]

Hi,

Java 1.5 comes with support for a new archive format Pack200[1] which
basically works by using a special compression algorithm that is very
effective on Java class files.  The way to create such an archive is
to create a plain old jar first and then turn ot into a Pack200
archive - "depack200"ing again yields a jar archive.

Sine Java 1.5 comes with a straight forward utility class[2], creating
 and  tasks would be quite simple - and first
enhancement request are predicted to pop up soon 8-)

Do we want to make them core tasks or do we want to farm them out into
an antlib of their own?

Stefan

Footnotes: 
[1]  http://jcp.org/en/jsr/detail?id=200

[2]  http://java.sun.com/j2se/1.5.0/docs/api/javax/pack/Pack200.html


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

DO NOT REPLY [Bug 3198] - The task doesn't work properly with multi-element sourceparh

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=3198

The  task doesn't work properly with multi-element sourceparh





--- Additional Comments From [EMAIL PROTECTED]  2004-02-10 10:01 ---
The issue with the javac task is I think the fact that it is a
 MatchingTask and cannot take embebedd filesets as nested elements.

The person  wants to do this:

javac -sourcepath src1;src2 src1/x/Test.java src2/x/AnotherClass.java

where src2/x/Test.java and src1/x/AnotherClass.java may exist, but
the user does not want to compile them.

A javac task with embedded srcfileset may look like this:
  
   
 
  
  


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

Re: multi-result s

[Peter Reilly]

Antoine Lévy-Lambert wrote:
I do not know whether it is 100% related,
but there is an open bug 
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3198 concerning the 
 task
in the case where the same source file is present in several source 
paths.

Will we be better fit to solve this problem with the new mapper 
infrastructure ?
No I do not think so.
The issue with the javac task is I think the fact that it is a 
MatchingTask and cannot take
embebedd filesets as nested elements.

The person  wants to do this:
javac -sourcepath src1;src2 src1/x/Test.java src2/x/AnotherClass.java
where src2/x/Test.java and src1/x/AnotherClass.java may exist, but the user 
does not want to compile them.
A javac task with embedded srcfileset may look like this:
  
   
 
  
  

Peter

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

RE: [GUMP@lsd]: ant/test-ant failed

[Jan . Materne]

http://lsd.student.utwente.nl/gump/ant/work/build_ant_test-ant.html

[junit] Testsuite: org.apache.tools.ant.taskdefs.JarTest
[junit] Tests run: 23, Failures: 1, Errors: 0, Time elapsed: 40.177 sec

[junit] Testcase:
testRecreateWithUpdateNewerFile(org.apache.tools.ant.taskdefs.JarTest):
FAILED
[junit] jar has been recreated in testRecreateWithUpdateNewerFile
[junit] junit.framework.AssertionFailedError: jar has been recreated in
testRecreateWithUpdateNewerFile
[junit] at junit.framework.Assert.fail(Assert.java:47)
[junit] at junit.framework.Assert.assertTrue(Assert.java:20)
[junit] at
org.apache.tools.ant.taskdefs.JarTest.testRecreate(JarTest.java:139)
[junit] at
org.apache.tools.ant.taskdefs.JarTest.testRecreateWithUpdateNewerFile(JarTes
t.java:121)

[junit] TEST org.apache.tools.ant.taskdefs.JarTest FAILED





> -Original Message-
> From: Gump Integration Build [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 10, 2004 11:12 AM
> To: [EMAIL PROTECTED]
> Subject: [EMAIL PROTECTED]: ant/test-ant failed
> 
> 
> Project: test-ant
> State: Failed
> URL: http://lsd.student.utwente.nl/gump/ant/test-ant.html
> - G U M P Y
> 
> 
> Annotations:
>  - Error - Failed with reason build failed
> 
> 
> - G U M P Y
> Work Name: build_ant_test-ant (Type: Build)
> State: Failed
> Elapsed: 0 hours, 5 minutes, 44 seconds
> Command Line: java -Djava.awt.headless=true 
> -Xbootclasspath/p:/data/gump/xml-xerces2/java/build/xercesImpl
> .jar:/data/gump/xml-xerces2/java/build/xmlParserAPIs.jar:/data
> /gump/xml-commons/java/external/build/xml-apis.jar:/data/gump/
> xml-xalan/java/build/xalan-unbundled.jar 
> org.apache.tools.ant.Main -Dbuild.clonevm=true 
> -Dgump.merge=/data/gump/gump/work/merge.xml 
> -Dbuild.sysclasspath=only -Dtest.haltonfailure=false 
> -Dant.home=/data/gump/ant/dist -Dhave.cvs=true run-tests 
> [Working Directory: /data/gump/ant]
> -
> 
> [junit] Testsuite: 
> org.apache.tools.ant.util.regexp.JakartaRegexpRegexpTest
> [junit] Tests run: 15, Failures: 0, Errors: 0, Time 
> elapsed: 0.054 sec
> 
> 
> [junit] Testsuite: 
> org.apache.tools.ant.util.regexp.Jdk14RegexpMatcherTest
> [junit] Tests run: 12, Failures: 0, Errors: 0, Time 
> elapsed: 0.006 sec
> 
> 
> [junit] Testsuite: 
> org.apache.tools.ant.util.regexp.Jdk14RegexpRegexpTest
> [junit] Tests run: 15, Failures: 0, Errors: 0, Time 
> elapsed: 0.007 sec
> 
> 
> [junit] Testsuite: org.apache.tools.mail.MailMessageTest
> [junit] Tests run: 7, Failures: 0, Errors: 0, Time 
> elapsed: 0.364 sec
> 
> 
> [junit] Testsuite: org.apache.tools.tar.TarEntryTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time 
> elapsed: 0.011 sec
> 
> 
> [junit] Testsuite: org.apache.tools.tar.TarRoundTripTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time 
> elapsed: 0.037 sec
> 
> 
> [junit] Testsuite: org.apache.tools.zip.AsiExtraFieldTest
> [junit] Tests run: 3, Failures: 0, Errors: 0, Time 
> elapsed: 0.016 sec
> 
> 
> [junit] Testsuite: org.apache.tools.zip.ExtraFieldUtilsTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time 
> elapsed: 0.025 sec
> 
> 
> [junit] Testsuite: org.apache.tools.zip.ZipEntryTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time 
> elapsed: 0.027 sec
> 
> 
> [junit] Testsuite: org.apache.tools.zip.ZipLongTest
> [junit] Tests run: 4, Failures: 0, Errors: 0, Time 
> elapsed: 0.005 sec
> 
> 
> [junit] Testsuite: org.apache.tools.zip.ZipShortTest
> [junit] Tests run: 4, Failures: 0, Errors: 0, Time 
> elapsed: 0.005 sec
> 
> 
> 
> BUILD FAILED
> /data/gump/ant/build.xml:1565: At least one test has failed.
> 
> Total time: 5 minutes 42 seconds
> -
> 
> - G U M P Y
> RSS: http://lsd.student.utwente.nl/gump/ant/test-ant.rss | 
> Atom: http://lsd.student.utwente.nl/gump/ant/test-ant.atom
> 
> --
> Gump http://jakarta.apache.org/gump
> [lsd]
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

[GUMP@lsd]: ant/test-ant failed

[Gump Integration Build]

Project: test-ant
State: Failed
URL: http://lsd.student.utwente.nl/gump/ant/test-ant.html
- G U M P Y


Annotations:
 - Error - Failed with reason build failed


- G U M P Y
Work Name: build_ant_test-ant (Type: Build)
State: Failed
Elapsed: 0 hours, 5 minutes, 44 seconds
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/data/gump/xml-xerces2/java/build/xercesImpl.jar:/data/gump/xml-xerces2/java/build/xmlParserAPIs.jar:/data/gump/xml-commons/java/external/build/xml-apis.jar:/data/gump/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main -Dbuild.clonevm=true 
-Dgump.merge=/data/gump/gump/work/merge.xml -Dbuild.sysclasspath=only 
-Dtest.haltonfailure=false -Dant.home=/data/gump/ant/dist -Dhave.cvs=true 
run-tests 
[Working Directory: /data/gump/ant]
-

[junit] Testsuite: org.apache.tools.ant.util.regexp.JakartaRegexpRegexpTest
[junit] Tests run: 15, Failures: 0, Errors: 0, Time elapsed: 0.054 sec


[junit] Testsuite: org.apache.tools.ant.util.regexp.Jdk14RegexpMatcherTest
[junit] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 0.006 sec


[junit] Testsuite: org.apache.tools.ant.util.regexp.Jdk14RegexpRegexpTest
[junit] Tests run: 15, Failures: 0, Errors: 0, Time elapsed: 0.007 sec


[junit] Testsuite: org.apache.tools.mail.MailMessageTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.364 sec


[junit] Testsuite: org.apache.tools.tar.TarEntryTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.011 sec


[junit] Testsuite: org.apache.tools.tar.TarRoundTripTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.037 sec


[junit] Testsuite: org.apache.tools.zip.AsiExtraFieldTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.016 sec


[junit] Testsuite: org.apache.tools.zip.ExtraFieldUtilsTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.025 sec


[junit] Testsuite: org.apache.tools.zip.ZipEntryTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.027 sec


[junit] Testsuite: org.apache.tools.zip.ZipLongTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.005 sec


[junit] Testsuite: org.apache.tools.zip.ZipShortTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.005 sec



BUILD FAILED
/data/gump/ant/build.xml:1565: At least one test has failed.

Total time: 5 minutes 42 seconds
-

- G U M P Y
RSS: http://lsd.student.utwente.nl/gump/ant/test-ant.rss | Atom: 
http://lsd.student.utwente.nl/gump/ant/test-ant.atom

--
Gump http://jakarta.apache.org/gump
[lsd]

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

RE: Ant 2.0

[Jan . Materne]

> > One thing that was voted on (positively, I recall), way  way back in
> > time, was for Ant2.0 to fail on undefined properties.
> 
> Although I've never looked into it, can't you already have it with a
> custom PropertyHelper?  If you can ensure that your custom property
> helper is the last one that gets called - and that it never gets
> called for know properties - you should be there.
> 
> Provide this property helper and maybe add a new command line switch
> as syntactic sugar, done.
> 
> > 3. But there would be a non-throwing expansion method for code that
> > explicitly wanted to not fail on missing strings in their .
> 
> The PropertyHelper could deal with it.
> 
> Stefan


BTW, in proposal/embed is a PropertyHelper which creates a list from a XML
file
and an XPath. Reading that was my first step on PropertyHelpers...

Jan

Re: Faulty classpath Ant 1.6 Launcher issue

[Conor MacNeill]

On Tue, 10 Feb 2004 08:26:43 +0100, Stefan Bodewig <[EMAIL PROTECTED]> 
wrote:

On Mon, 9 Feb 2004, Dominique Devienne <[EMAIL PROTECTED]> wrote:
FWIW, I could finally get a hold of a CLASSPATH value that triggers
the infamous IllegalArgumentException at
sun.net.www.ParseUtil.decode(ParseUtil.java:155) issue with the new
Ant 1.6 launcher.
Did you have a chance to try with a recent CVS snapshot?  I think I've
seen a commit by Conor that was supposed to fix the issue.
It was supposed to but It was a little shortsighted.
I'll add another fix.
Conor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: can I change junit runner main class

[Stefan Bodewig]

On Mon, 09 Feb 2004, Mariano Benitez <[EMAIL PROTECTED]> wrote:

> The problem is that I cannot simulate this using JUnit with
> fork, because I cannot change the main class and use mine
> instead.

I assume that your class understands all the command line arguments
Ant's testrunner uses and passes them along.  How would your class
deal with new arguments we add?

The main problem with opening up access to the test runner class is
just that.  As soon as we do it, we run the risk of breaking other
people's builds when we change the protocol between the task and the
test runner.  There is no danger now, as we always know the main class
that gets invoked.

> 1) leave  and have "launcher"
> script change the command line

Ugly but portable accross Ant versions.

> 2) patch junit to allow me to put a boot class
> 3) extend junit (the problem is that JUnitTask.executeAsForked and
> commandline are private, so I should patch the task anyway)

Both cases are dangerous for us to do as they make future development
more difficult for us.  If we'd choose either one, we'd have to come
up with a strict contract for the boot class first.

Stefan

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

Re: Faulty classpath Ant 1.6 Launcher issue

[Stefan Bodewig]

On Mon, 9 Feb 2004, Dominique Devienne <[EMAIL PROTECTED]> wrote:

> FWIW, I could finally get a hold of a CLASSPATH value that triggers
> the infamous IllegalArgumentException at
> sun.net.www.ParseUtil.decode(ParseUtil.java:155) issue with the new
> Ant 1.6 launcher.

Did you have a chance to try with a recent CVS snapshot?  I think I've
seen a commit by Conor that was supposed to fix the issue.

Stefan

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

DO NOT REPLY [Bug 26814] - empty includesfile in fileset includes all files in dir

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=26814

empty includesfile in fileset includes all files in dir

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-02-10 07:26 ---
This is the standard behavior of ant. If you have a fileset containing no
include elements, then everything *except* the default excludes (like *~,
**/CVS/*, ...) is included under the base dir of your fileset.
As you say, including one dummy file in your fileset stops this behavior.
So I am closing your bug report as Invalid.

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

Re: multi-result s

[Stefan Bodewig]

On Mon, 9 Feb 2004, Matt Benson <[EMAIL PROTECTED]> wrote:

> So... does anyone have a problem with changing the recommended usage
> of s while maintaining BC?

No problem at all, in particular if the part starting with "while"
holds true 8-)

Stefan

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

Re: multi-result s

[Antoine Lévy-Lambert]

Matt Benson wrote:
Stefan and I talked about doing one of these here:
http://marc.theaimsgroup.com/?l=ant-user&m=107487826503877&w=2
Peter and I each produced a different implementation. 
See
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26364
for our discussion.  In the end Peter's changes are
probably more powerful than mine but his specific
implementation represents a paradigm shift, hence our
decision to start a thread devoted to the issue.

s have always been specified via a 
element and either a "type" or "classname" attribute,
which actually specified an implementation of
FileNameMapper.  Peter's proposition allows to define
the implementation type directly in
types/defaults.properties, then nest these directly
into the  element.  In this way s
would/could look a lot more like s and
s, especially when ref'd.  Another note is
that adding new core mappers would be a properties
file (or other typedef) edit rather than a change to
an EnumeratedAttribute.  Finally, this allows more
specialized attributes on mappers than just "to" and
"from".  So... does anyone have a problem with
changing the recommended usage of s while
maintaining BC?
-Matt
__
 

This sounds good.
I do not know whether it is 100% related,
but there is an open bug 
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3198 concerning the 
 task
in the case where the same source file is present in several source paths.

Will we be better fit to solve this problem with the new mapper 
infrastructure ?

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

DO NOT REPLY [Bug 19807] - CvsChangeLog to support revision tag parameter

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=19807

CvsChangeLog to support revision tag parameter





--- Additional Comments From [EMAIL PROTECTED]  2004-02-10 07:21 ---
ant 1.6.1 has added support for branches in cvschangelog, and changed the
implementation of the class to make it extend CvsAbstractTask.
Would you like to have a look at it and prepare new patches to add your
functionality in CVS HEAD for ant 1.7 ?

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

DO NOT REPLY [Bug 26814] New: - empty includesfile in fileset includes all files in dir

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=26814

empty includesfile in fileset includes all files in dir

   Summary: empty includesfile in fileset includes all files in dir
   Product: Ant
   Version: 1.6.1beta1
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I'm using an automated process (an XSLT transformation) to generate a file list 
that is used in a later task to create a fileset. The problem comes when there 
are no files to be added to the fileset. In that case, the includesfile is 
empty. Intuitively, I expected that the following fileset definition would 
include no files when tutorial-1-graphics.txt is empty (0 bytes).



Instead, what happens is that the fileset contains *all* the files 
in /pubs/clementine/images instead of no files.

I can work around it by always writing at least one bogus file to the 
includesfile (zzz.zzz or something like that), but it seems to me that a 
fileset that uses an empty file to construct its include list ought to end up 
with no files in it.

If I've missed something here, and this behavior is designed or intentional, 
perhaps someone would be good enough to point out the logic behind it. (I'm 
pretty new to Ant, so it's entirely possible that I just don't understand quite 
as well as I think I do.) Thanks.

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