DO NOT REPLY [Bug 18391] - RFE: ignoreMissingBuildFiles option for subant

[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=18391

RFE: ignoreMissingBuildFiles option for subant





--- Additional Comments From [EMAIL PROTECTED]  2003-03-26 22:09 ---
I agree with the current default. I can see utility in both directions. In my
case I am willing to commit to being sure that the build file is there, because
the target I am writing is for develop-time compiling of multiple packages that
rely on a library (which I am going to edit and don't want to break). But when
deploying a product it would be very bad to silently ignore a missing build file
because the finished product that was deployed might come out broken. I think
Dominique got it right, I just want the ability to loosen things up.

hehe mid-aired... 

hmm the fileset solution does sound like it would work. I suppose that pushes my
patch into  the realm of syntax sugar... I kinda like it though because it suits
how I think about the problem...

DO NOT REPLY [Bug 18391] - RFE: ignoreMissingBuildFiles option for subant

[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=18391

RFE: ignoreMissingBuildFiles option for subant





--- Additional Comments From [EMAIL PROTECTED]  2003-03-26 21:54 ---
Then you could have simply specified a fileset...

Assuming:


  


using 


  


Would only have found the *existing* build files. Not need for a patch in this 
case, and still as order less as before. --DD

DO NOT REPLY [Bug 18391] - RFE: ignoreMissingBuildFiles option for subant

[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=18391

RFE: ignoreMissingBuildFiles option for subant





--- Additional Comments From [EMAIL PROTECTED]  2003-03-26 21:51 ---
I'm not following Steve... What does cheesy means in this context?

 can take a  or a  or whatever else a path can take. 
java.io.Files which are not build files (i.e. !isFile() || isDirectory()) are 
appended the default build file name ('antfile' attribute, same as  BTW). 
Of course, like in most places in Ant, explicitly telling a task to do 
something that missing the essential processing unit, the build file, is an 
error by default in .

What is wrong with that? I guess I'm not following... --DD

DO NOT REPLY [Bug 18391] - RFE: ignoreMissingBuildFiles option for subant

[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=18391

RFE: ignoreMissingBuildFiles option for subant





--- Additional Comments From [EMAIL PROTECTED]  2003-03-26 21:48 ---
Actually I was giving it a DirSet :) and letting it just look for build.xml in
each directory. Seems to work great on my machine with my patch applied.

DO NOT REPLY [Bug 18391] - RFE: ignoreMissingBuildFiles option for subant

[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=18391

RFE: ignoreMissingBuildFiles option for subant





--- Additional Comments From [EMAIL PROTECTED]  2003-03-26 21:43 ---
I'd have expected the project to take a fileset, and you'd just say
server/*/build.xml. But I get the implication that directories without a
build.xml fail? That's cheesy. 

Given this task is in its infancy, I'm happy with not only the change, but any
underlying behaviour changes we need (i.e. get the defaults right)

URGENT: problem installing Ant

[Cristina Surroca]

Hi!
I'm doing a project with Postgresql and I need to use JDBC.
I've got a problem installing ant (I use SUSE). When I try to execute ant is
trhown this exeption:


 Exception in thread "main" java.lang.NoClassDefFoundError:
org/apache/tools/ant/Main

my PATH:

echo $PATH
>/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/X11R6/bin:/bin
:/usr/games/bin:/usr/games:/opt/gnome/bin:/usr/local/soft/jdk1.3.1_07/:/usr/
local/src/apache-ant-1.5.2

and I've done also:
  
JAVA_HOME=/usr/local/soft/jdk1.3.1_07
export JAVA_HOME


  
ANT_HOME=/usr/local/src/apache-ant-1.5.2
export ANT_HOME


Does anyone know what I'm doing wrong?

Thanks

Cris..

Re: [patch] [bugfix] IntrospectionHelper.java

[Neeme Praks]

ok, fair enough. I sent a patch to commons-dev with a workaround for 
Jelly anyway... just have to check back now if the patch was actually 
noticed or not ;-)

Stefan Bodewig ::
On 26 Mar 2003, Stefan Bodewig <[EMAIL PROTECTED]> wrote:

I'm going to throw in the extra check in CVS HEAD later
today/tomorrow.

I spoke too soon.  Given the javadocs:
 * Stores a named nested element using a storage method determined
 * by the initial introspection. If no appropriate storage method
 * is available, this method returns immediately.
it would be a break of backwards compatibility if we started to throw
an exception instead of simply returning, sorry.
Stefan

DO NOT REPLY [Bug 18391] - RFE: ignoreMissingBuildFiles option for subant

[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=18391

RFE: ignoreMissingBuildFiles option for subant





--- Additional Comments From [EMAIL PROTECTED]  2003-03-26 21:34 ---
Hmmm, I never thought that would be an issue, as I've never setup a buildpath 
that includes sub-projects without a build file, but I guess it could be useful 
to some people (obviously ;-). I would definitely keep the current default 
behavior though, as you indicated you did in your patch. --DD

DO NOT REPLY [Bug 18391] - RFE: ignoreMissingBuildFiles option for subant

[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=18391

RFE: ignoreMissingBuildFiles option for subant





--- Additional Comments From [EMAIL PROTECTED]  2003-03-26 21:30 ---
Created an attachment (id=5523)
A patch to add ignoreMissingBuildFiles atribute to subant

DO NOT REPLY [Bug 18391] New: - RFE: ignoreMissingBuildFiles option for subant

[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=18391

RFE: ignoreMissingBuildFiles option for subant

   Summary: RFE: ignoreMissingBuildFiles option for subant
   Product: Ant
   Version: 1.6Alpha (nightly)
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I was just fooling around with subant, and became really annoyed that it failed
every time it couldn't find a build file, but I definately wanted it to fail if
any of the subbuilds failed. 

I decided it was faster and prevented future maintainence to patch subant than
specifically exclude directories that happened to live at the same level, but
don't yet have build files or don't need them. 

So the request is for the addition of a ignoreMissingBuildFiles atribute for
subant. It should of course default to false to preserve the existing behavior,
and when true cause subant to simply ignore any specified build file that is not
found. (thus ignoring both a missing (default) build.xml, and any explicit build
file that doesn't exist) so here comes the patch...

Ant extension points (was RE: Artima SuiteRunner Task)

[Dominique Devienne]

After much head scratching, I came up with a solution to my own little Ant
extension problem (about which I complained about a few months back).
Basically, I first had to use Parametrizable to enable the extension point,
like other Ant types:


  
  


The solution was the introduction of a DynamicTag class which uses both
DynamicConfigurator and UnknownElement. I can now define my extension point
(which implements an interface/extension point only my datatype cares about)
using a , and then use it (and configure it as any other task) like
so:


  



BuildPath.java adds a nested creator:

/**
 * Creates a nested resolver element to contain a user-defined
 * resolver dynamically parameterized thanks to DynamicTag.
 */
public Object createResolver() {
return _dynaResolver = new DynamicTag(BuildPathResolver.class);
}

And uses it like so when declared:

if (_dynaResolver != null) {
BuildPathResolver resolver;
resolver = (BuildPathResolver)_dynaResolver.getTag(0);
return resolver.getBuildPath();
}

DynamicTag does the magic, i.e. ensure it contains as many nested elements
as specified (default to requiring exactly one element), and also ensures
that these elements are of the correct type (i.e. assigneable to the
specified class/interface).

This always the extension point to be configured like any other Ant
task/type, including proper conversion to File, int, etc...

My only concern is the lack of namespaces (not the XML type) for all the
declarations of tasks/types/custom extension points. I initially coded a
role manager class, but would have had to modify Ant core in many places to
use it, so reverted to subverting the existing type system of Ant.

This extension point mechanism could be used in place of Peter's patch to
enable custom selector/mappers/etc... I believe.

Let me all know what you think of it. --DD

// vim:ts=4:sw=4
package com.lgc.buildmagic;

import java.util.List;
import java.util.Arrays;
import java.util.ArrayList;
import java.util.Collections;

import org.apache.tools.ant.Task;
import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.UnknownElement;
import org.apache.tools.ant.RuntimeConfigurable;
import org.apache.tools.ant.DynamicConfigurator;

/**
 * Tag allowing creation of arbitrary bean/type/tasks registered with Ant
 * using either a taskdef or typedef.
 *
 * @author mailto:[EMAIL PROTECTED]">Dominique Devienne
 * @version Mar 2003 - Copyright (c) 2002, Landmark Graphics Corp.
 */
public class DynamicTag
 extends Task
 implements DynamicConfigurator {

/** List of tags actually instantiated. */
private List _tags;

/** Class(es) this/these dynamic tag(s) must be compatible with. */
private List _types;

/** Minimum number of dynamic tags to create. Defaults to 1. */
private int _atLeast = 1;

/** Maximum number of dynamic tags to create. Defaults to 1. */
private int _atMost = 1;

/**
 * Instantiates a new dynamic tag that accepts only one arbitrary
Object.
 */
public DynamicTag() {
this(null);
}

/**
 * Instantiates a new dynamic tag that accepts only one given Object
 * assignable to the given required type.
 *
 * @param  requiredType the class this dynamic tag's only child must
 * be compatible with, in the [EMAIL PROTECTED] 
Class#isAssignableWith}
 * sense. Can be null.
 */
public DynamicTag(Class requiredType) {
if (requiredType != null) {
_types = new ArrayList(1);
_types.add(requiredType);
}
}

/**
 * Instantiates a new dynamic tag that accepts Objects
 * assignable to the given required types.
 *
 * @param  requiredTypes the classes this dynamic tag's only child must
 * be compatible with, in the [EMAIL PROTECTED] 
Class#isAssignableWith}
 * sense. Can be null.
 * @param  atLeast the minimum number of beans/types/tasks this
 * dynamic element should contain. Must not be negative,
 * or strictly greater than atMost.
 * Use 0 (zero) for no lower bound.
 * @param  atMost the maximum number of beans/types/tasks this
 * dynamic element should contain. Must not be negative, zero,
 * or strictly smaller than atLeast.
 * Use [EMAIL PROTECTED] Integer#MAX_INT} for no upper bound.
 */
public DynamicTag(Class[] requiredTypes, int atLeast, int atMost) {
if (atLeast < 0 || atLeast > atMost || atMost == 0) {
throw new IllegalArgumentException("Invalid min/max: " +
   atLeast + '/' + atMost);
}
if (requiredTypes != null && requiredTypes.length > 0) {
_types = Arrays.asList(requiredTypes);
}
_atLeast = atLeast;
_atMost = atMost;
}

Re: Artima SuiteRunner Task

[Costin Manolache]

peter reilly wrote:

> I would include filters, mappers, conditions and selectors to
> the list.

I would exclude them :-)

Taks, types, mappers, filters, whatever are just ant components - 
and they shouldn't need a special syntax from user perspective.

We shouldn't treat them ( or types, tasks ) as special - just plain
components that happen to perform different functions in the build file.


> A relatively simple mod to the core ant makes this
> possible (bugzilla 17199) basically get ConditionBase.java,
> AbstractFileSet, FilterChain implement DynamicConfigurator.
> and get UnknownElement (bugzilla 18312) call setProject
> earlier on created children.
> Mappers are a little different, I implemented a new
> attribute to handle this.

That's a possible solution, I'll take a look ( in few weeks
unfortunately..., hopefully this will be resolved by than by others :-).

DO NOT REPLY [Bug 18312] - [PATCH] New tokenfilter for filterchain

[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=18312

[PATCH] New tokenfilter for filterchain

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|[EMAIL PROTECTED]  |[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-03-26 19:08 ---
Peter, 
Patch 5494 alone is obsolete, right?  Please list the patches that are 
relevant, for clarity's sake.  Please also supply unit tests and I will
commit it.  Thanks for the patch.  It addresses an enhancement that has been
requested often.

DO NOT REPLY [Bug 18312] - [PATCH] New tokenfilter for filterchain

[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=18312

[PATCH] New tokenfilter for filterchain





--- Additional Comments From [EMAIL PROTECTED]  2003-03-26 18:58 ---
Updated patch:

build.xml : conditionally compile scriptfilter.java
src/main/org/apache/tools/ant/types/defaults.properties : add scriptfilter
docs/manual/CoreTypes/filterchain.html : update html page
   - add scriptfilter
   - change tokenhandler to string filter

DO NOT REPLY [Bug 18312] - [PATCH] New tokenfilter for filterchain

[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=18312

[PATCH] New tokenfilter for filterchain





--- Additional Comments From [EMAIL PROTECTED]  2003-03-26 18:56 ---
Created an attachment (id=5518)
new cvs diff -u for affected ant core files

DO NOT REPLY [Bug 18312] - [PATCH] New tokenfilter for filterchain

[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=18312

[PATCH] New tokenfilter for filterchain





--- Additional Comments From [EMAIL PROTECTED]  2003-03-26 18:55 ---
Created an attachment (id=5517)
source for org.apache.tools.ant.types.optional.ScriptFilter

DO NOT REPLY [Bug 18166] - Concat enhancement

[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=18166

Concat enhancement





--- Additional Comments From [EMAIL PROTECTED]  2003-03-26 18:43 ---
Created an attachment (id=5516)
Add fixes,  input encoding and textelement file not present, add comments

Re: Artima SuiteRunner Task

[peter reilly]

I would include filters, mappers, conditions and selectors to
the list.

A relatively simple mod to the core ant makes this
possible (bugzilla 17199) basically get ConditionBase.java,
AbstractFileSet, FilterChain implement DynamicConfigurator.
and get UnknownElement (bugzilla 18312) call setProject
earlier on created children.
Mappers are a little different, I implemented a new
attribute to handle this.

It this is done, then non ant core projects may implement
their own whacky types.

(like this to convert to upper case:


 
 self.setToken(self.getToken().toUpperCase())
 
 



Peter

On Wednesday 26 March 2003 17:46, Costin Manolache wrote:
> Dominique Devienne wrote:
> > Hu, not totally. If the AntLib also uses types, you need another
> > , which should also probably needs a loaderref. Since you now
> > use twice the classpath, if needs to be outside and refid'd.
>
> In ant1.6 the difference between tasks and types is very small. It would be
> trivial to load both of them at once.
>
> In any case, I don't quite agree with Stefan: the simpler solution is:
>
>  
>
>  
>
> I would love to completely remove the different treatment of types -
> i.e. a task is just like a type with an execute() method, and nothing else,
> and  loades both kinds.
>
> That would be simpler than the current syntax that also require you to
> do a:
>  
>
> Costin
>
> > And what about the  task? I'd like to not have setup my classpath
> > outside of Ant and build.xml, and avoid having to dump everything in
> > AntLib.
> >
> > I believe it can and should be easier and more flexible. --DD
> >
> > -Original Message-
> > From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, March 26, 2003 10:27 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Artima SuiteRunner Task
> >
> > On Wed, 26 Mar 2003, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> >> That said (one more ;-), if Ant ever comes up with an easier way to
> >> integrate third party tasks
> >
> > Easier than ?
> >
> > Almost impossible.
> >
> > Stefan
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

Re: Artima SuiteRunner Task

[Nicola Ken Barozzi]

Costin Manolache wrote, On 26/03/2003 18.46:
Dominique Devienne wrote:

Hu, not totally. If the AntLib also uses types, you need another
, which should also probably needs a loaderref. Since you now use
twice the classpath, if needs to be outside and refid'd.

In ant1.6 the difference between tasks and types is very small. It would be
trivial to load both of them at once.
+1
It makes sense also because it's typical for tasks to need a certain 
typedef, and separating the declaration is simply wrong in these cases.

In any case, I don't quite agree with Stefan: the simpler solution is:
 
 
 

I would love to completely remove the different treatment of types - 
i.e. a task is just like a type with an execute() method, and nothing else,
and  loades both kinds.

That would be simpler than the current syntax that also require you to 
do a: 
 
Do we have a real-world candidate for
  
or
  
or
  
?
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Re: Artima SuiteRunner Task

[Steve Loughran]

Chris Reeves wrote:
Ah - ok. 

And proof that no matter how tattered the pages of my copy of JDWA are,
there's more gems to be found within.
Thanks!
Chris
I believe that particular snippet is a near-direct cut and paste from 
ant's own build file. So the credit goes to whoever set up the  
task in ant's build.xml


---
Actually, of all the pet peeves about junit, I have the following
1. I'd like logging integrated with ant log levels, even across processes
2 I want the notion of 'tests that fail but we dont consider 
showstoppers'; these are 'expected failures'. Its nice to know when 
these go away, and its nice to know when they fail in a different place 
or for a different reason from before, but I dont want the build 
stopping 'cos a test for a known bug is blocking everything.

-steve

RE: Artima SuiteRunner Task

[Costin Manolache]

Dominique Devienne wrote:


> Hu, not totally. If the AntLib also uses types, you need another
> , which should also probably needs a loaderref. Since you now use
> twice the classpath, if needs to be outside and refid'd.
> 
> And what about the  task? I'd like to not have setup my classpath
> outside of Ant and build.xml, and avoid having to dump everything in
> ANT_HOME/lib

That works fine ( for me ). As soon as I finish with the current deadline
I'll document the  task which solves this problem.


Costin



> 
> I believe it can and should be easier and more flexible. --DD
> 
> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 26, 2003 10:27 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Artima SuiteRunner Task
> 
> On Wed, 26 Mar 2003, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> 
>> That said (one more ;-), if Ant ever comes up with an easier way to
>> integrate third party tasks
> 
> Easier than ?
> 
> Almost impossible.
> 
> Stefan

Re: Request for downloadable Ant Manual in pdf Thank you

[Steve Loughran]

Stefan Bodewig wrote:
On Tue, 25 Mar 2003, Steve Loughran <[EMAIL PROTECTED]> wrote:

I am sure we could probably do a PDF build from the xdocs stuff now,

I'm sure, too.

if we somehow create docbook content via XSLT, velocity, whatever.

Why docbook?  You could create the XSL:FO directly, no?
I s'pose so.

>Please note that this is not the official
>documentation.  When in doubt, please consult the online manual.
then the source :)

8-)
I completely realize that Erik and you have helped to improve the
manual a lot (and not just the manual) while writing the book, because
you've used the source.  It's just that 1.5.3 is a bit different from
1.5 in some places.
I strongly agree. I also think the pdf docs make the redist much bigger 
than they need be.

cvs commit: ant/docs/manual/CoreTasks subant.html whichresource.html

[stevel]

stevel  2003/03/26 09:55:37

  Added:   docs/manual/CoreTasks subant.html whichresource.html
  Log:
  manual insertion of xdocs pages
  
  Revision  ChangesPath
  1.1  ant/docs/manual/CoreTasks/subant.html
  
  Index: subant.html
  ===
  
  
  

Subant
   Task
  
  
  
  
  
  


  


  Subant
   Task
  EXPERIMENTAL: 
This task is experimental and may be under continual change till Ant1.6 ships; 
it may even be omitted from the product.


  
  http://ant.apache.org/";>

  


  

  


  
  

  
  
 
  

  

Description

  

  EXPERIMENTAL: This task is experimental and may be under 
continual change till Ant1.6 ships; it may even be omitted from the product. 
 Calls a given target for all defined sub-builds. This is an extension of 
ant for bulk project execution.

  
  
  
  
  
  
 
  

  

Parameters

  

  

  
Attribute
  
  
Description
  
  
Type
  

  
  
  
antfile
  
  

Sets the default build file name to append to directory names found 
in the build path -default "build.xml"
  
  
  
String
  
  
  
  
  
buildpath
  
  

Set the buildpath to be used to find sub-projects.
  
  
  
Path
  
  
  
  
  
buildpathref
  
  

Buildpath to use, by reference.
  
  
  
Reference
  
  
  
  
  
failonerror
  
  

Sets whether to fail with a build exception on error, or go on.
  
  
  
boolean
  
  
  
  
  
inheritall
  
  

Corresponds to 's inheritall 
attribute.
  
  
  
boolean
  
  
  
  
  
inheritrefs
  
  

Corresponds to 's inheritrefs 
attribute.
  
  
  
boolean
  
  
  
  
  
target
  
  

  
  
  
String
  
  
  
  

  
  
  
  
  
  
 
  

  

Parameters as nested elements

  

  
  
 

  
dirset (org.apache.tools.ant.types.DirSet)


  Adds a directory set to the implicit build path.  Note that 
the directories will be added to the build path in no particular order, so if 
order is significant, one should use a file list instead!
  
  

  
  

  
  
  
  
 

  
filelist 
(org.apache.tools.ant.types.FileList)


  Adds an ordered file list to the implicit build path.  Note 
that contrary to file and directory sets, file lists can reference non-existent 
files or directories!
  
  

  
  

  
  
  
  
 

  
fileset (org.apache.tools.ant.types.FileSet)


  Adds a file set to the implicit build path.  Note that the 
directories will be added to the build path in no particular order, so if order 
is significant, one should use a file list instead!
  
  

  
  

  
  
  
  
 

  
property 
(org.apache.tools.ant.taskdefs.Property)


  Corresponds to 's nested 
 element.
  
  

  
  

  
  
  
  
 

  
reference 
(org.apache.tools.ant.taskdefs.Ant.Reference)


  Corresponds to 's nested 
 element.
  
  

  
  

  
  
  
  
 

  
buildpath (org.apache.tools.ant.types.Path)


  Creates a nested build path, and add it to the implicit build path.
  
  

  
  

  
  
  
  
 

  
   

RE: Artima SuiteRunner Task

[Costin Manolache]

Dominique Devienne wrote:

> Hu, not totally. If the AntLib also uses types, you need another
> , which should also probably needs a loaderref. Since you now use
> twice the classpath, if needs to be outside and refid'd.

In ant1.6 the difference between tasks and types is very small. It would be
trivial to load both of them at once.

In any case, I don't quite agree with Stefan: the simpler solution is:

 
 
 

I would love to completely remove the different treatment of types - 
i.e. a task is just like a type with an execute() method, and nothing else,
and  loades both kinds.

That would be simpler than the current syntax that also require you to 
do a: 
 

Costin



> 
> And what about the  task? I'd like to not have setup my classpath
> outside of Ant and build.xml, and avoid having to dump everything in
> AntLib.
> 
> I believe it can and should be easier and more flexible. --DD
> 
> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 26, 2003 10:27 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Artima SuiteRunner Task
> 
> On Wed, 26 Mar 2003, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> 
>> That said (one more ;-), if Ant ever comes up with an easier way to
>> integrate third party tasks
> 
> Easier than ?
> 
> Almost impossible.
> 
> Stefan

RE: Artima SuiteRunner Task

[Dominique Devienne]

I don't buy that. If your exception doesn't contain enough info, then modify
the exception. I never trap exception in Unit tests, unless I'm expecting it
to be thrown and fail() if it doesn't.

As far as running one of more tests, I use a
-Dtestcase=com/acme/SomeTest.class, and testcases defaultsto
**/test/*Test.class if not explicitly specified.

Like I said, I'm still trying to understand what SuiteRunner brings to the
table... I even prefer the distinction between Failures and Errors... With
JUnit 3.8.1, I even write test cases with just test methods and nothing else
(if one doesn't use setUp/tearDown).

I looked at SuiteRunner because of the talk about Conformance/API testing,
and it doesn't bring anything above JUnit at all. Like I said, I'm still
waiting to be enlightened about SuiteRunner's cons ;-) --DD


-Original Message-
From: Nathaniel Spurling [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2003 11:08 AM
To: Ant Developers List
Subject: Re: Artima SuiteRunner Task


On Wednesday, March 26, 2003, at 11:46  AM, Nathaniel Spurling wrote:
   >
   > Regarding suiterunner vs JUnit, I prefer the suiterunner API:
   >
   >   test methods can throw Exceptions, also assertion failures
   > generate Exceptions so you can put one catch(Exception) at the bottom
   > of your method and print out any useful info before throwing the
   > exception on, rather than separate ones for AssertionFailedError and
   > Exception which looks very messy. Alternatively you can leave out the
   > try/catch altogether  - saves typing if you just want the stacktrace
   > -- I Don't find the failures/exceptions distinction useful in JUnit.

   I often simply have my JUnit testXXX throw Exception since that is
   unexpected and a test failure/error.  I don't quite get how SuiteRunner
   is different here.


say you've got a method which goes:

  testXXX() throws Exception{

//generate random data

try{
  //do testing

} catch(Exception e){
  //print data used
  throw e;
}
  }

 in JUnit you need an extra catch(AssertionFailedError) clause in the event
of an assertion being untrue - not a big difference, but if all your tests
are the same format it's preferable.



--

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.



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

DO NOT REPLY [Bug 16455] - Ant should not require DTD file listed in DOCTYPE to exist

[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=16455

Ant should not require DTD file listed in DOCTYPE to exist





--- Additional Comments From [EMAIL PROTECTED]  2003-03-26 17:11 ---
How do the editors suggest tags without the DTD? (I generally don't use a
specialized xml editor, though that is something I have been meaning to get
around to). Do your editor have some sort of internal knowledge of ant files? If
you have the DTD for the editor, how do you wind up not having it for running
the antfile?

Re: Artima SuiteRunner Task

[Nathaniel Spurling]

On Wednesday, March 26, 2003, at 11:46  AM, Nathaniel Spurling wrote:
   >
   > Regarding suiterunner vs JUnit, I prefer the suiterunner API:
   >
   >   test methods can throw Exceptions, also assertion failures
   > generate Exceptions so you can put one catch(Exception) at the bottom
   > of your method and print out any useful info before throwing the
   > exception on, rather than separate ones for AssertionFailedError and
   > Exception which looks very messy. Alternatively you can leave out the
   > try/catch altogether  - saves typing if you just want the stacktrace
   > -- I Don't find the failures/exceptions distinction useful in JUnit.

   I often simply have my JUnit testXXX throw Exception since that is
   unexpected and a test failure/error.  I don't quite get how SuiteRunner
   is different here.


say you've got a method which goes:

  testXXX() throws Exception{

//generate random data

try{
  //do testing

} catch(Exception e){
  //print data used
  throw e;
}
  }

 in JUnit you need an extra catch(AssertionFailedError) clause in the event of 
an assertion being untrue - not a big difference, but if all your tests are the 
same format it's preferable.



--

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is strictly 
forbidden.

RE: Artima SuiteRunner Task

[Chris Reeves]

Ah - ok. 

And proof that no matter how tattered the pages of my copy of JDWA are,
there's more gems to be found within.

Thanks!

Chris

> -Original Message-
> From: Steven Newton [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, March 26, 2003 12:05 PM
> To: Ant Developers List
> Subject: RE: Artima SuiteRunner Task
> 
> 
> I do it with one line in my build.xml:
>  if="testcase"/> and a small change to the batchtest task: 
> 
> 
> Both of these in are my "test" target, so I just run ant with 
> ant -Dtestcase=com.whatever.TestWhatever test
> 
> Easy!  And thanks to Erik's book for the tip.
> 
> s
> 
> -Original Message-
> From: Chris Reeves [mailto:[EMAIL PROTECTED] 
> 
> How do you set it up to run a single test on demand?
> 
> I could set a different target for each test (painful) or use 
> a command line param with -D (less painful but no idea).
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

Re: Artima SuiteRunner Task

[Erik Hatcher]

On Wednesday, March 26, 2003, at 12:01  PM, Chris Reeves wrote:
Erik -
How do you set it up to run a single test on demand?
Like this:
http://www.ehatchersolutions.com/JavaDevWithAnt/junit.html

RE: Artima SuiteRunner Task

[Steven Newton]

I do it with one line in my build.xml:

and a small change to the batchtest task:


Both of these in are my "test" target, so I just run ant with
ant -Dtestcase=com.whatever.TestWhatever test

Easy!  And thanks to Erik's book for the tip.

s

-Original Message-
From: Chris Reeves [mailto:[EMAIL PROTECTED] 

How do you set it up to run a single test on demand?

I could set a different target for each test (painful) or use a command
line param with -D (less painful but no idea).

RE: Artima SuiteRunner Task

[Chris Reeves]

> -Original Message-
> From: Erik Hatcher [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, March 26, 2003 11:55 AM
> To: Ant Developers List
> Subject: Re: Artima SuiteRunner Task


 
>  and  in Ant support if/unless properties 
> and I always 
> have it set up to be able to run a single test upon demand.



Erik - 

How do you set it up to run a single test on demand?

I could set a different target for each test (painful) or use a command
line param with -D (less painful but no idea).

Chris

Re: Artima SuiteRunner Task

[Erik Hatcher]

On Wednesday, March 26, 2003, at 11:46  AM, Nathaniel Spurling wrote:
Regarding suiterunner vs JUnit, I prefer the suiterunner API:
  test methods can throw Exceptions, also assertion failures 
generate Exceptions so you can put one catch(Exception) at the bottom 
of your method and print out any useful info before throwing the 
exception on, rather than separate ones for AssertionFailedError and 
Exception which looks very messy. Alternatively you can leave out the 
try/catch altogether  - saves typing if you just want the stacktrace 
-- I Don't find the failures/exceptions distinction useful in JUnit.
I often simply have my JUnit testXXX throw Exception since that is 
unexpected and a test failure/error.  I don't quite get how SuiteRunner 
is different here.

  don't have to call super(String) - me being lazy again
This went away with JUnit 3.8 - thankfully!  That was my biggest pet 
peeve of JUnit.

  which tests run can be determined by a property file so if you 
want to run just a few tests out of a suite you don't need to 
recompile/comment out bits of code
 and  in Ant support if/unless properties and I always 
have it set up to be able to run a single test upon demand.

  can also put classpath info in the property file, which seems 
better than adding it to your junit script or CLASSPATH
Not usually an issue when using Ant and  with a reusable 
classpath.

  flexible reporting of results - which you already mentioned - 
and which I haven't used...
more flexible than ?
Erik

DO NOT REPLY [Bug 17408] - 6 New ClearCase Tasks Created

[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=17408

6 New ClearCase Tasks Created

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|[EMAIL PROTECTED]  |[EMAIL PROTECTED]

RE: Artima SuiteRunner Task

[Nathaniel Spurling]

Regarding suiterunner vs JUnit, I prefer the suiterunner API:

  test methods can throw Exceptions, also assertion failures generate 
Exceptions so you can put one catch(Exception) at the bottom of your method and 
print out any useful info before throwing the exception on, rather than 
separate ones for AssertionFailedError and Exception which looks very messy. 
Alternatively you can leave out the try/catch altogether  - saves typing if you 
just want the stacktrace -- I Don't find the failures/exceptions distinction 
useful in JUnit.

  don't have to call super(String) - me being lazy again

  which tests run can be determined by a property file so if you want to 
run just a few tests out of a suite you don't need to recompile/comment out 
bits of code

  can also put classpath info in the property file, which seems better than 
adding it to your junit script or CLASSPATH

  flexible reporting of results - which you already mentioned - and which I 
haven't used...

Nat




 
  Dominique 
 
  Devienne To:   "'Ant Developers 
List'" <[EMAIL PROTECTED]>  
  
  <[EMAIL PROTECTED]cc: 
  
  m>   Subject:  RE: Artima SuiteRunner 
Task 

 
  26.03.2003 15:19  
 
  Please respond to 
 
  "Ant Developers   
 
  List" 
 

 

 




Could someone please explain me what SuiteRunner brings to the table that
JUnit doesn't I've looked at it quite a bit, and maybe beside better
reporting, I don't see anything compelling about it compared to JUnit, and
even loose the built-in assert methods of TestCase (thru Assert)...

I'd be interested in knowing what other see in it. Thanks, --DD

-Original Message-
From: Adam Duffy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2003 5:09 AM
To: Ant Developers List
Subject: Artima SuiteRunner Task

Hi All,

(Please forgive my newbie-ness).

I have developed an Ant Task for the Artima SuiteRunner and I'd like to
submit it. Perhaps a Committer might a respond directly and I'll e-mail them
a zip file containing the code? (Didn't want to send a zip file to a few
hundred people...!)

Thanks,

Adam Duffy
Crypto Group
Computer Science Dept
NUI Maynooth

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






--

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is strictly 
forbidden.

Re: Artima SuiteRunner Task

[Stefan Bodewig]

On Wed, 26 Mar 2003, Dominique Devienne <[EMAIL PROTECTED]> wrote:

> Hu, not totally.

Did I forget to put that smiley in?

> Since you now use twice the classpath, if needs to be outside and
> refid'd.

No, you'll need to use the loaderref attribute.

> And what about the  task?

Easy in Ant 1.6, it comes in a jar of its own.

Ant's default install will most probably need to keep it on the system
classpath.  This backwards compatibility thing, you know.

> I believe it can and should be easier and more flexible.

Agreed.

Stefan

Re: Artima SuiteRunner Task

[peter reilly]

Unless the tasks require changes to core ant  :-)~

Peter.

On Wednesday 26 March 2003 16:26, Stefan Bodewig wrote:
> On Wed, 26 Mar 2003, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > That said (one more ;-), if Ant ever comes up with an easier way to
> > integrate third party tasks
>
> Easier than ?
>
> Almost impossible.
>
> Stefan
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

RE: Artima SuiteRunner Task

[Dominique Devienne]

I meant ANT_HOME/lib. --DD

-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2003 10:37 AM
To: 'Ant Developers List'
Subject: RE: Artima SuiteRunner Task

Hu, not totally. If the AntLib also uses types, you need another
, which should also probably needs a loaderref. Since you now use
twice the classpath, if needs to be outside and refid'd.

And what about the  task? I'd like to not have setup my classpath
outside of Ant and build.xml, and avoid having to dump everything in
ANT_HOME/lib

I believe it can and should be easier and more flexible. --DD

-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2003 10:27 AM
To: [EMAIL PROTECTED]
Subject: Re: Artima SuiteRunner Task

On Wed, 26 Mar 2003, Dominique Devienne <[EMAIL PROTECTED]> wrote:

> That said (one more ;-), if Ant ever comes up with an easier way to
> integrate third party tasks

Easier than ?

Almost impossible.

Stefan

RE: Artima SuiteRunner Task

[Dominique Devienne]

Hu, not totally. If the AntLib also uses types, you need another
, which should also probably needs a loaderref. Since you now use
twice the classpath, if needs to be outside and refid'd.

And what about the  task? I'd like to not have setup my classpath
outside of Ant and build.xml, and avoid having to dump everything in AntLib.

I believe it can and should be easier and more flexible. --DD

-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2003 10:27 AM
To: [EMAIL PROTECTED]
Subject: Re: Artima SuiteRunner Task

On Wed, 26 Mar 2003, Dominique Devienne <[EMAIL PROTECTED]> wrote:

> That said (one more ;-), if Ant ever comes up with an easier way to
> integrate third party tasks

Easier than ?

Almost impossible.

Stefan

Re: Artima SuiteRunner Task

[Stefan Bodewig]

On Wed, 26 Mar 2003, Dominique Devienne <[EMAIL PROTECTED]> wrote:

> That said (one more ;-), if Ant ever comes up with an easier way to
> integrate third party tasks

Easier than ?

Almost impossible.

Stefan

RE: Ant task and dirset/fileset

[Dominique Devienne]

 is stand alone (not the very latest version with the dependency
stuff), i.e. a single Java file. The version integrated to Ant removes the
magic of inferring the target to call from the current target (which is why
you thought all the targets do the same thing... They all call a different
target name, which defaults to the one they are declared within, if not is
explicitly specified.

Even if it's removed from Ant 1.6 official, nothing prevents you (or me) to
continue using it. The choice is yours. --DD

-Original Message-
From: Gus Heck [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2003 9:58 AM
To: Ant Developers List
Subject: Re: Ant task and dirset/fileset

Hmm I notice that the source is marked as experimental and subject to 
change. Is this still true? To what extent. I am slightly leary of 
upgrading to an alpha branch for our builds, particularly if the 
compelling feature is going to be a moving target :)

Also in your example buildfile, I am not sure I understand how the 
targets work. It looks like clean, build reversion and rebuild all do 
the same thing?

-Gus

Dominique Devienne wrote:
> No doc, no test :-(
> 
> Subant accept a , which is a regular  (accepts nested
> , , etc...
> 
> Subant's buildpath can be specified either outside (and referenced using
> buildpathref) or inside (subant contains an implicit buildpath, so you can
> add a  or  directly within subant).
> 
> All files all the build path (it's a path, so it's ordered) that is a
> directory is appended build.xml, or the value of the 'antfile' attribute
if
> specified. By default, subant calls the target it's defined within
> automatically, or the target explicitly defined in the 'target' attribute.
> 
> Supports all  attributes (except 'dir' and 'output') and nested
> elements, and adds the 'failonerror' attribute, and nested
>  elements to
> compose the build path within.
> 
> Hope that helps. --DD
> 
> -Original Message-
> From: Gus Heck [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, March 25, 2003 4:07 PM
> To: Ant Developers List
> Subject: Re: Ant task and dirset/fileset
> 
> Ok I searched bugzilla and subant appears exactly once... but it says it 
> is committed. Problem is I don't see it in the manual, where can I get 
> some doc for it? (or do I need to go find that link to the xdocs that I 
> forgot to bookmark?)
> 
> -Gus
> 
> Dominique Devienne wrote:
> 
>>Yes ;-) Me, and other people too. There is in Ant's BugZilla one task
> 
> called
> 
>> that was recently added to the HEAD (slightly modified) on an
>>experimental basis, and there's also a patch to  along the same
> 
> lines.
> 
>>There has been quite a bit of discussion about both (one vs. the other
> 
> even)
> 
>>on ant-dev as well. You should look it all up.
>>
>>As the original author and user of , I can tell you it's working
>>just fine for me. Here's one of my build files, for example. Should be
>>familiar to Makefile writers (it does build C++ libraries after all ;-)
>>
>>
>>
>>
>>
>>  
>>  
>>
>>  
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>
>>
>>-Original Message-
>>From: Gus Heck [mailto:[EMAIL PROTECTED] 
>>Sent: Tuesday, March 25, 2003 3:34 PM
>>To: [EMAIL PROTECTED]
>>Subject: Ant task and dirset/fileset
>>
>>Has anyone ever thought about or tried to make the ant task accept a 
>>fileset or dirset? I have a use for such functionality but, before I go 
>>writing myself a custom version, or writing a patch, I thought I might 
>>ask if this has been tried, is being tried, or has be explicitly decided 
>>against?
>>
>>-Gus
>>
>>-
>>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]
> 



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

Re: Ant task and dirset/fileset

[Gus Heck]

Hmm I notice that the source is marked as experimental and subject to 
change. Is this still true? To what extent. I am slightly leary of 
upgrading to an alpha branch for our builds, particularly if the 
compelling feature is going to be a moving target :)

Also in your example buildfile, I am not sure I understand how the 
targets work. It looks like clean, build reversion and rebuild all do 
the same thing?

-Gus
Dominique Devienne wrote:
No doc, no test :-(
Subant accept a , which is a regular  (accepts nested
, , etc...
Subant's buildpath can be specified either outside (and referenced using
buildpathref) or inside (subant contains an implicit buildpath, so you can
add a  or  directly within subant).
All files all the build path (it's a path, so it's ordered) that is a
directory is appended build.xml, or the value of the 'antfile' attribute if
specified. By default, subant calls the target it's defined within
automatically, or the target explicitly defined in the 'target' attribute.
Supports all  attributes (except 'dir' and 'output') and nested
elements, and adds the 'failonerror' attribute, and nested
 elements to
compose the build path within.
Hope that helps. --DD
-Original Message-
From: Gus Heck [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 25, 2003 4:07 PM
To: Ant Developers List
Subject: Re: Ant task and dirset/fileset

Ok I searched bugzilla and subant appears exactly once... but it says it 
is committed. Problem is I don't see it in the manual, where can I get 
some doc for it? (or do I need to go find that link to the xdocs that I 
forgot to bookmark?)

-Gus
Dominique Devienne wrote:
Yes ;-) Me, and other people too. There is in Ant's BugZilla one task
called
 that was recently added to the HEAD (slightly modified) on an
experimental basis, and there's also a patch to  along the same
lines.
There has been quite a bit of discussion about both (one vs. the other
even)
on ant-dev as well. You should look it all up.
As the original author and user of , I can tell you it's working
just fine for me. Here's one of my build files, for example. Should be
familiar to Makefile writers (it does build C++ libraries after all ;-)


 
 
 
   
   
   
   
   
   
   
   
   
   
   
 
 
   
 
 
   
 
 
   
 
 
   
 

-Original Message-
From: Gus Heck [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 25, 2003 3:34 PM
To: [EMAIL PROTECTED]
Subject: Ant task and dirset/fileset

Has anyone ever thought about or tried to make the ant task accept a 
fileset or dirset? I have a use for such functionality but, before I go 
writing myself a custom version, or writing a patch, I thought I might 
ask if this has been tried, is being tried, or has be explicitly decided 
against?

-Gus
-
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: Artima SuiteRunner Task

[Dominique Devienne]

That said (by Erik and myself), if SuiteRunner becomes popular enough (like
JUnit), and even though it's an 'external' task, there would be a good
possibility that it could be incorporated in ant-optional.jar, simply to
help and evangelize Unit Testing in general, which is a  best practice.

That said (one more ;-), if Ant ever comes up with an easier way to
integrate third party tasks (and their dependencies) using an AntLib
mechanism, maybe it would not make it to Ant, just because it would be so
easy to integrate anyhow.

I hope this helps, --DD

-Original Message-
From: Adam Duffy [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2003 10:00 AM
To: Ant Developers List
Subject: RE: Artima SuiteRunner Task

Thanks Dominique,

I wasn't aware of that policy regarding 'external' tasks (since I only
started subscribing recently). I'll ask Artima.com to see if their
interested. :)

Thanks again,
Adam

-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Sent: 26 March 2003 15:37
To: 'Ant Developers List'
Subject: RE: Artima SuiteRunner Task


Sorry, I didn't mean at all to put down your contribution. I was more asking
an off topic question about SuiteRunner. My personal opinion on SuiteRunner
is not binding in any way the Ant community at large, or the committers ;-)

As a note, past comments indicate that Task should ideally live within the
tool they Ant-enable (and depend on), so your contribution maybe should also
be made (or instead) to the Artima.com SuiteRunner community. --DD

-Original Message-
From: Adam Duffy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2003 9:36 AM
To: Ant Developers List
Subject: RE: Artima SuiteRunner Task

Hi Dominique,

I would like to know what other people think too.

If at the end of the day, the developers of Ant do not wish to use the code
I have written, that is fine with me. I only want to contribute to the
development of Ant - which I am really fond of. As does Leigh Ishikawa. Any
advice on that matter?

Thanks,
Adam

-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Sent: 26 March 2003 15:20
To: 'Ant Developers List'
Subject: RE: Artima SuiteRunner Task


Could someone please explain me what SuiteRunner brings to the table that
JUnit doesn't I've looked at it quite a bit, and maybe beside better
reporting, I don't see anything compelling about it compared to JUnit, and
even loose the built-in assert methods of TestCase (thru Assert)...

I'd be interested in knowing what other see in it. Thanks, --DD

-Original Message-
From: Adam Duffy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2003 5:09 AM
To: Ant Developers List
Subject: Artima SuiteRunner Task

Hi All,

(Please forgive my newbie-ness).

I have developed an Ant Task for the Artima SuiteRunner and I'd like to
submit it. Perhaps a Committer might a respond directly and I'll e-mail them
a zip file containing the code? (Didn't want to send a zip file to a few
hundred people...!)

Thanks,

Adam Duffy
Crypto Group
Computer Science Dept
NUI Maynooth

-
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: Artima SuiteRunner Task

[Stefan Bodewig]

On Wed, 26 Mar 2003, Adam Duffy <[EMAIL PROTECTED]> wrote:

> Myself and Leigh Ishikawa ("Adding 'setName' support to the
> xmljunitresultformatter.java") have not received any response to our
> contributions. Can someone please advise?

First advice would be to be more patient, four hours isn't that much
8-)

Looking into contributions is something that takes time and all of us
here are volunteers.  It is not unusual to get no response for days,
and I'll admit that occasionally there will be no response at all.

In your case, I have no idea what Artima SuiteRunner is, so a
contribution that focusses on it will not catch my attention.  It will
go into a queue of mails and I'll hope that another committer -
somebody who knows what you are talking about ;-) - will get to it
first.  Dominique's comments suggest that it is some kind of testing
tool, nice.

So now the more general response: For quite some time we've become
very reluctant to add new tasks.  Especially tasks that are tied to
third party products - we generally prefer to see them outside of Ant
and with this product.

The reason is that Ant already contains far too many tasks that no
committer can really test and support - this leaves us in a position
where we are not doing any good to our users, nor to ourselves.

Tasks have to be supported.  If no committer is able to support it
directly, we have to rely on people less tightly connected to Ant.  In
many cases the original authors of a task have disappeared and when we
receive patches for their tasks, reviewing those patches becomes
painful.

Cheers

Stefan

RE: Artima SuiteRunner Task

[Adam Duffy]

Thanks Dominique,

I wasn't aware of that policy regarding 'external' tasks (since I only
started subscribing recently). I'll ask Artima.com to see if their
interested. :)

Thanks again,
Adam

-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Sent: 26 March 2003 15:37
To: 'Ant Developers List'
Subject: RE: Artima SuiteRunner Task


Sorry, I didn't mean at all to put down your contribution. I was more asking
an off topic question about SuiteRunner. My personal opinion on SuiteRunner
is not binding in any way the Ant community at large, or the committers ;-)

As a note, past comments indicate that Task should ideally live within the
tool they Ant-enable (and depend on), so your contribution maybe should also
be made (or instead) to the Artima.com SuiteRunner community. --DD

-Original Message-
From: Adam Duffy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2003 9:36 AM
To: Ant Developers List
Subject: RE: Artima SuiteRunner Task

Hi Dominique,

I would like to know what other people think too.

If at the end of the day, the developers of Ant do not wish to use the code
I have written, that is fine with me. I only want to contribute to the
development of Ant - which I am really fond of. As does Leigh Ishikawa. Any
advice on that matter?

Thanks,
Adam

-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Sent: 26 March 2003 15:20
To: 'Ant Developers List'
Subject: RE: Artima SuiteRunner Task


Could someone please explain me what SuiteRunner brings to the table that
JUnit doesn't I've looked at it quite a bit, and maybe beside better
reporting, I don't see anything compelling about it compared to JUnit, and
even loose the built-in assert methods of TestCase (thru Assert)...

I'd be interested in knowing what other see in it. Thanks, --DD

-Original Message-
From: Adam Duffy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2003 5:09 AM
To: Ant Developers List
Subject: Artima SuiteRunner Task

Hi All,

(Please forgive my newbie-ness).

I have developed an Ant Task for the Artima SuiteRunner and I'd like to
submit it. Perhaps a Committer might a respond directly and I'll e-mail them
a zip file containing the code? (Didn't want to send a zip file to a few
hundred people...!)

Thanks,

Adam Duffy
Crypto Group
Computer Science Dept
NUI Maynooth

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

Re: Artima SuiteRunner Task

[Erik Hatcher]

As Dominique mentioned, what the Ant developers typically try to do 
these days is push back on 3rd party integration built into Ant and let 
these custom tasks live with the project they support.  It would be 
easier for maintenance for us committers, since none of (probably) use 
Artima SuiteRunner and it would house the tasks closest to those that 
can support it best.

Another option would be to host the custom tasks at your own website or 
Sourceforge and we'll gladly update the Ant documentation to refer 
there.

Or keep lobbying and perhaps another Ant committer is interested in 
adding this.  I have no objections, but I personally don't use 
SuiteRunner and don't want to get into maintaining corresponding Ant 
tasks myself.

Erik
On Wednesday, March 26, 2003, at 10:36  AM, Adam Duffy wrote:
Hi Dominique,
I would like to know what other people think too.
If at the end of the day, the developers of Ant do not wish to use the 
code
I have written, that is fine with me. I only want to contribute to the
development of Ant - which I am really fond of. As does Leigh 
Ishikawa. Any
advice on that matter?

Thanks,
Adam
-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Sent: 26 March 2003 15:20
To: 'Ant Developers List'
Subject: RE: Artima SuiteRunner Task
Could someone please explain me what SuiteRunner brings to the table 
that
JUnit doesn't I've looked at it quite a bit, and maybe beside 
better
reporting, I don't see anything compelling about it compared to JUnit, 
and
even loose the built-in assert methods of TestCase (thru Assert)...

I'd be interested in knowing what other see in it. Thanks, --DD
-Original Message-
From: Adam Duffy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2003 5:09 AM
To: Ant Developers List
Subject: Artima SuiteRunner Task
Hi All,
(Please forgive my newbie-ness).
I have developed an Ant Task for the Artima SuiteRunner and I'd like to
submit it. Perhaps a Committer might a respond directly and I'll 
e-mail them
a zip file containing the code? (Didn't want to send a zip file to a 
few
hundred people...!)

Thanks,
Adam Duffy
Crypto Group
Computer Science Dept
NUI Maynooth
-
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/unix Symlink.java

[bodewig]

bodewig 2003/03/26 07:50:28

  Modified:src/main/org/apache/tools/ant/taskdefs/optional/unix
Symlink.java
  Log:
  Fix javadocs.
  
  PR: 17143
  Submitted by: Gus Heck
  
  Revision  ChangesPath
  1.4   +7 -7  
ant/src/main/org/apache/tools/ant/taskdefs/optional/unix/Symlink.java
  
  Index: Symlink.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/unix/Symlink.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- Symlink.java  10 Feb 2003 14:14:28 -  1.3
  +++ Symlink.java  26 Mar 2003 15:50:28 -  1.4
  @@ -141,12 +141,12 @@
* absolute paths. On non-unix systems this may cause false positives. 
* Furthermore, any operating system on which the command 
* ln -s link resource is not a valid command on the comandline 
  - * will not be able to use action="single" or action="multi" action="record"
  - * should still work. Finally, the lack of support for symlinks in Java
  - * means that all links are recorded as links to the 
  - * canonical resource name. Therefore the link:
  - * link --> subdir/dir/../foo.bar will be recorded as
  - * link=subdir/foo.bar and restored as 
  + * will not be able to use action= "delete", action="single" or 
  + * action="recreate", but action="record" should still work. Finally, the 
  + * lack of support for symlinks in Java means that all links are recorded 
  + * as links to the canonical resource name. Therefore 
  + * the link: link --> subdir/dir/../foo.bar will be recorded 
  + * as link=subdir/foo.bar and restored as 
* link --> subdir/foo.bar
*
* @version $Revision$
  
  
  

DO NOT REPLY [Bug 8080] - New task to compile Python code in java bytecode

[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=8080

New  task to compile Python code in java bytecode

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-03-26 15:40 ---
*** Bug 18363 has been marked as a duplicate of this bug. ***

DO NOT REPLY [Bug 18363] - jythonc task

[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=18363

jythonc task

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-03-26 15:40 ---


*** This bug has been marked as a duplicate of 8080 ***

RE: Artima SuiteRunner Task

[Dominique Devienne]

Sorry, I didn't mean at all to put down your contribution. I was more asking
an off topic question about SuiteRunner. My personal opinion on SuiteRunner
is not binding in any way the Ant community at large, or the committers ;-)

As a note, past comments indicate that Task should ideally live within the
tool they Ant-enable (and depend on), so your contribution maybe should also
be made (or instead) to the Artima.com SuiteRunner community. --DD

-Original Message-
From: Adam Duffy [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2003 9:36 AM
To: Ant Developers List
Subject: RE: Artima SuiteRunner Task

Hi Dominique,

I would like to know what other people think too.

If at the end of the day, the developers of Ant do not wish to use the code
I have written, that is fine with me. I only want to contribute to the
development of Ant - which I am really fond of. As does Leigh Ishikawa. Any
advice on that matter?

Thanks,
Adam

-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Sent: 26 March 2003 15:20
To: 'Ant Developers List'
Subject: RE: Artima SuiteRunner Task


Could someone please explain me what SuiteRunner brings to the table that
JUnit doesn't I've looked at it quite a bit, and maybe beside better
reporting, I don't see anything compelling about it compared to JUnit, and
even loose the built-in assert methods of TestCase (thru Assert)...

I'd be interested in knowing what other see in it. Thanks, --DD

-Original Message-
From: Adam Duffy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2003 5:09 AM
To: Ant Developers List
Subject: Artima SuiteRunner Task

Hi All,

(Please forgive my newbie-ness).

I have developed an Ant Task for the Artima SuiteRunner and I'd like to
submit it. Perhaps a Committer might a respond directly and I'll e-mail them
a zip file containing the code? (Didn't want to send a zip file to a few
hundred people...!)

Thanks,

Adam Duffy
Crypto Group
Computer Science Dept
NUI Maynooth

RE: Artima SuiteRunner Task

[Adam Duffy]

Hi Dominique,

I would like to know what other people think too.

If at the end of the day, the developers of Ant do not wish to use the code
I have written, that is fine with me. I only want to contribute to the
development of Ant - which I am really fond of. As does Leigh Ishikawa. Any
advice on that matter?

Thanks,
Adam

-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Sent: 26 March 2003 15:20
To: 'Ant Developers List'
Subject: RE: Artima SuiteRunner Task


Could someone please explain me what SuiteRunner brings to the table that
JUnit doesn't I've looked at it quite a bit, and maybe beside better
reporting, I don't see anything compelling about it compared to JUnit, and
even loose the built-in assert methods of TestCase (thru Assert)...

I'd be interested in knowing what other see in it. Thanks, --DD

-Original Message-
From: Adam Duffy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2003 5:09 AM
To: Ant Developers List
Subject: Artima SuiteRunner Task

Hi All,

(Please forgive my newbie-ness).

I have developed an Ant Task for the Artima SuiteRunner and I'd like to
submit it. Perhaps a Committer might a respond directly and I'll e-mail them
a zip file containing the code? (Didn't want to send a zip file to a few
hundred people...!)

Thanks,

Adam Duffy
Crypto Group
Computer Science Dept
NUI Maynooth

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

RE: Artima SuiteRunner Task

[Dominique Devienne]

Could someone please explain me what SuiteRunner brings to the table that
JUnit doesn't I've looked at it quite a bit, and maybe beside better
reporting, I don't see anything compelling about it compared to JUnit, and
even loose the built-in assert methods of TestCase (thru Assert)...

I'd be interested in knowing what other see in it. Thanks, --DD

-Original Message-
From: Adam Duffy [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2003 5:09 AM
To: Ant Developers List
Subject: Artima SuiteRunner Task

Hi All,

(Please forgive my newbie-ness).

I have developed an Ant Task for the Artima SuiteRunner and I'd like to
submit it. Perhaps a Committer might a respond directly and I'll e-mail them
a zip file containing the code? (Didn't want to send a zip file to a few
hundred people...!)

Thanks,

Adam Duffy
Crypto Group
Computer Science Dept
NUI Maynooth

RE: Artima SuiteRunner Task

[Adam Duffy]

Hi,

Myself and Leigh Ishikawa ("Adding 'setName' support to the
xmljunitresultformatter.java") have not received any response to our
contributions. Can someone please advise?

Cheers,
Adam

-Original Message-
From: Adam Duffy [mailto:[EMAIL PROTECTED]
Sent: 26 March 2003 11:09
To: Ant Developers List
Subject: Artima SuiteRunner Task


Hi All,

(Please forgive my newbie-ness).

I have developed an Ant Task for the Artima SuiteRunner and I'd like to
submit it. Perhaps a Committer might a respond directly and I'll e-mail them
a zip file containing the code? (Didn't want to send a zip file to a few
hundred people...!)

Thanks,

Adam Duffy
Crypto Group
Computer Science Dept
NUI Maynooth


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

DO NOT REPLY [Bug 18363] New: - jythonc task

[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=18363

jythonc task

   Summary: jythonc task
   Product: Ant
   Version: 1.5.3
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


One should create a task to compile jython (JPython) scripts, allowing
developpers to extend Java classes with the Python scripting language.
Eventually one would need to collaborate with the Jython team.

[GUMP] Test Failure - Ant

[Diane Holt]

This email is autogenerated from the output from:



Build results exceed maximum length.
Please see URL above for details.
Last 50 lines of build output follows.


[junit] Testsuite: org.apache.tools.ant.AntClassLoaderTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.005 sec

[junit] Testsuite: org.apache.tools.ant.CaseTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.061 sec

[junit] Testsuite: org.apache.tools.ant.ImmutableTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.095 sec

[junit] Testsuite: org.apache.tools.ant.IncludeTest
[junit] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 0.314 sec

[junit] Testsuite: org.apache.tools.ant.IntrospectionHelperTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.017 sec

[junit] Testsuite: org.apache.tools.ant.LoaderRefTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.307 sec

[junit] Testsuite: org.apache.tools.ant.ProjectTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.115 sec

[junit] Testsuite: org.apache.tools.ant.PropertyExpansionTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.021 sec

[junit] Testsuite: org.apache.tools.ant.TopLevelTaskTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.142 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.024 sec

[junit] Testsuite: org.apache.tools.zip.ZipEntryTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.026 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.007 sec

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


BUILD FAILED
file:///home/rubys/jakarta/ant/build.xml:1645: At least one test has failed.

Total time: 9 minutes 30 seconds

Artima SuiteRunner Task

[Adam Duffy]

Hi All,

(Please forgive my newbie-ness).

I have developed an Ant Task for the Artima SuiteRunner and I'd like to
submit it. Perhaps a Committer might a respond directly and I'll e-mail them
a zip file containing the code? (Didn't want to send a zip file to a few
hundred people...!)

Thanks,

Adam Duffy
Crypto Group
Computer Science Dept
NUI Maynooth

Re: [patch] [bugfix] IntrospectionHelper.java

[Stefan Bodewig]

On 26 Mar 2003, Stefan Bodewig <[EMAIL PROTECTED]> wrote:

> I'm going to throw in the extra check in CVS HEAD later
> today/tomorrow.

I spoke too soon.  Given the javadocs:

 * Stores a named nested element using a storage method determined
 * by the initial introspection. If no appropriate storage method
 * is available, this method returns immediately.

it would be a break of backwards compatibility if we started to throw
an exception instead of simply returning, sorry.

Stefan

Re: [patch] [bugfix] IntrospectionHelper.java

[Stefan Bodewig]

On Wed, 26 Mar 2003, Neeme Praks <[EMAIL PROTECTED]> wrote:
> Stefan Bodewig ::
>> On Sat, 01 Mar 2003, Neeme Praks <[EMAIL PROTECTED]> wrote:
>>
>>>storeElement() method silently returns, if the tag does not support
>>>the specified element.
>>
>> This is because storeElement can never be called without calling
>> createElement before that from within Ant.  It may be different
>> from within Jelly, I don't know.
> 
> So, could we fix this?

Sure.  You mean you want to fix Jelly? 8-)

If you don't invoke createElement before you call storeElement, you
are probable in trouble anyway.

I'm going to throw in the extra check in CVS HEAD later
today/tomorrow.

Stefan

FixCrLf extension

[Ernst Plüss]

Hi All

I'm currently cleaning up a huge repository of source
files which have all kinds of line endings. So I had a
look at the FixCrLf task. Although FixCrLf basically
does what I'm looking for I need some more features:
a) checkout all the files with a wrong line ending
b) fix them
c) check them in
d) some kind of preview without touching a file

In order to do this I'm thinking of an aditional
parameter telling FixCrLf to produce a FileSet
containing all files not containing the requried line
endings.

What I do not like about this aproach, is the fact,
that I would have to manually copy the produced
FileSet into an other ant script to get a)-c) done.
May be there's a clever way to do this fully
automated.

WDYT?
Ernst

__

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Bis zu 100 MB Speicher bei http://premiummail.yahoo.de

Re: [patch] [bugfix] IntrospectionHelper.java

[Neeme Praks]

Stefan Bodewig ::
On Sat, 01 Mar 2003, Neeme Praks <[EMAIL PROTECTED]> wrote:
storeElement() method silently returns, if the tag does not support
the specified element.
This is because storeElement can never be called without calling
createElement before that from within Ant.  It may be different from
within Jelly, I don't know.
So, could we fix this? If it is never called without createElement, then 
it will not break anything in Ant, but it will make the code more 
consistent and it will help to fix Jelly.

I also fixed the supportsNestedElement() check as it did not check
for nestedStorers, only for nestedCreators.
nestedStorers' keys are a subset of nestedCreators' keys, aren't they?
So checking for the later should be sufficient.
ok, this is correct, just checking for nestedCreators should be enough...
Rgds,
Neeme

Re: Cygwin tester needed

[Stefan Bodewig]

On Tue, 25 Mar 2003, Stefan Moebius <[EMAIL PROTECTED]> wrote:

> warning: unportable BRE: `^/.*': using `^' as the first character of
> the basic regular expression is not portable;

That's funny.

The GNU man pages of expr(1) are a bit vague here (they talk about
"anchored" expressions in context of the : operator) - at least the
man pages installed on my RedHat 7.3 box.

The FreeBSD and Mac OS X pages state that a leading ^ would be added
implicitly and it seems to work on Solaris as well.  So I think we'll
go without the leading ^.  This seems to be POSIX.2 conformant as
well.

> So basically, the modification works as expected. 

Great, thanks.

Stefan

Re: Request for downloadable Ant Manual in pdf Thank you

[Stefan Bodewig]

On Tue, 25 Mar 2003, Steve Loughran <[EMAIL PROTECTED]> wrote:

> I am sure we could probably do a PDF build from the xdocs stuff now,

I'm sure, too.

> if we somehow create docbook content via XSLT, velocity, whatever.

Why docbook?  You could create the XSL:FO directly, no?

>  >Please note that this is not the official
>  >documentation.  When in doubt, please consult the online manual.
> 
> then the source :)

8-)

I completely realize that Erik and you have helped to improve the
manual a lot (and not just the manual) while writing the book, because
you've used the source.  It's just that 1.5.3 is a bit different from
1.5 in some places.

Stefan

Re: Cygwin tester needed

[Stefan Moebius]

Ok - I've installed 1.5.3b1 and replaced the wrapper script by HEAD.
Install dir: C:\apache-ant-1.5.3Beta1

Test 1:
ln -s /cygdrive/c/apache-ant-1.5.3Beta1/bin/ant /usr/local/bin/ant

without modification:
ANT_HOME=/cygdrive/c/apache-ant-1.5.3Beta1

with modification:
expr: warning: unportable BRE: `^/.*': using `^' as the first character
of the basic regular expression is not portable; it is being ignored
ANT_HOME=/cygdrive/c/apache-ant-1.5.3Beta1

with '/.*' instead of '^/.*':
ANT_HOME=/cygdrive/c/apache-ant-1.5.3Beta1

Test 2:
ln -s /cygdrive/c/apache-ant-1.5.3Beta1 /usr/local/ant
cd /usr/local/bin
ln -s ../ant/bin/ant ant

without modification:
shows the buggy behavior

with modification:
same as test 1

with '/.*' instead of '^/.*':
same as test 1

So basically, the modification works as expected. 

Stefan

--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> please take a look at
> .  I can
> reprodice this bug, but I'm afraid that the proposed patch will break
> Cygwin - as I have no idea how it handles absolute paths.
> 
> The change would be in line 54 of the ant wrapper script (CVS HEAD),
> instead of 
> 
> if expr "$link" : '.*/.*' > /dev/null; then
> 
> we'd use
> 
> if expr "$link" : '^/.*' > /dev/null; then
> 
> Oh, to run into this code, you must not set ANT_HOME and the script
> you invoke must be a symlink (is this possible on Cygwin?) to the
> real
> script.
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


=
Stefan Moebius   <[EMAIL PROTECTED]> 
  Wurzener Str. 43+49 351 8475827
  01127 Dresden   +49 172 8739617

__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

DO NOT REPLY [Bug 18352] New: - The filename and path of the build file that failed is printed out in URL encode format.

[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=18352

The filename and path of the build file that failed is printed out in URL 
encode format. 

   Summary: The filename and path of the build file that failed is
printed out in URL encode format.
   Product: Ant
   Version: 1.5.2
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The filename and path of the build.xml file is printed out in URL encoded 
format. 

This seems to be a side-effect of the change to a new version of Xerces, since 
the SAXParserException.getSystemId() returns the SystemId in URL encoded format 
(which is correct bahaviour from the parser's point of view, I think). The 
problem basically is that the systemId is incorrectly assigned to the Location 
object to represent a filename.

The effect of this is that some software (eg. IDEs), that are using Ant, are 
not able to open the correct file when the build fails, because the filename is 
not actually a filename.

A workaround would be to parse the filename from the SystemId and to decode the 
escape characters.

Re: JBuilder & Gel IDE Integration

[Paul King]

Stefan Bodewig wrote:
On Tue, 25 Mar 2003, Paul King <[EMAIL PROTECTED]> wrote:

GEL IDE for Windows
License: 	Freeware

Isn't very specific and the site doesn't seem to give more details.
I've downloaded the latest RC to see whether there are more license
details but the setup.exe doesn't do any good on my Linux box 8-)
Could you please take a look and pull out the exact words of the
license?  Freeware is applied to software licensed under GPL as well
as stuff that is in the public domain.
To clarify, source isn't available but there are no fees or restrictions 
on its use.  Checked with the author and he is happy with it being 
described as "Freeware" or perhaps "Freeware, no source" if greater 
accuracy is required.

Cheers, Paul.
P.S. Another suggestion: the external.html page has no internal 
navigation to get to the three sections: "Tasks", "Compiler 
Implementations" and "IDE and Editor Integration" and it has grown into 
a rather a long page these days.  Perhaps we can change the wording at 
the top from

"This page lists external resources for Apache Ant: tasks, IDE 
integration tools, loggers, you name it."

to
"This page lists external resources for Apache Ant: Tasks, Compiler 
Implementations, IDE & Editor Tools, you name it."

And make the "Tasks", "Compiler Implementations" etc href links to some 
internal anchor tags?

Just a small cosmetic suggestion if someone is already in the file doing 
updates.  (Sorry, I know I should be looking at doing diff's but I 
haven't looked into how the doco is generated these days).

Cheers, Paul.