subtitute copy with dir

2003-05-02 Thread Dibi, George 
 
Can someone tell me how to display a content of a directory using xml?
 
Sample code.

DO NOT REPLY [Bug 19603] New: - Property task with file attribute only suppoer ansi charset

2003-05-02 Thread 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=19603

Property task with file attribute only suppoer ansi charset

   Summary: Property task with file attribute only suppoer ansi
charset
   Product: Ant
   Version: 1.5.3
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Property task with file attribute only suppoer ansi charset, if specified 
property file contains chars of other charset in name or value, such as UTF-
8,GB2312,etc., the property name or value is incorrect. i saw the source of 
Property.java, it is caused in loadFile(File file), it uses Properties.load
(InputStream in) to load properties, and it doesn't other charset encodings.

DO NOT REPLY [Bug 19601] - Add 'Thumbs.db' to default exclude list.

2003-05-02 Thread 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=19601

Add 'Thumbs.db' to default exclude list.





--- Additional Comments From [EMAIL PROTECTED]  2003-05-02 16:35 ---
Created an attachment (id=6170)
Patch to update DirectoryScanner.java and dirtask.html

DO NOT REPLY [Bug 19601] New: - Add 'Thumbs.db' to default exclude list.

2003-05-02 Thread 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=19601

Add 'Thumbs.db' to default exclude list.

   Summary: Add 'Thumbs.db' to default exclude list.
   Product: Ant
   Version: unspecified
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Thumbs.db is a file made by Windows XP, very similar to .DS_Store, and should 
be excluded by default.

Re: Roles (was: antlib)

2003-05-02 Thread peter reilly 
Yes, but more infrastructure is needed.
(Also, in current ant cvs, ComponentHelper is not used).

My knowledge on this subject is very small, but here
is my understanding (based on looking at jelly source
code).

To support XML ns one needs to know the uri associated
with the namespace prefix.

The same prefix may be associated with different uri in
the course of processing an xml file.

By overriding sax.helpers.DefaultHandler#startPrefixMapping
and #stopPrefixMapping, one can find out when the prefix
mapping space is active and when it is terminated. This is what
jelly does.

It would be more difficult (I may be wrong here) for ant to use
this information as resolving of most of  tags is done after the xml
parsing has completed.

It is not necessary to do this as .DefaultHander#startElement
does pass the uri that is associated with the element. This
could get stored in the UnknownElement and used for
name resolution. (Attributes would also be be considered).

Since namespace processing is active, the code should
use getLocalName and not getQName.

To support antlibs, I am thinking that one could have a
mapping table per uri (for element tags), either within
the ComponentHelper, or have a ComponentHelper per uri.

Peter


On Friday 02 May 2003 15:42, Costin Manolache wrote:
> peter reilly wrote:
>
> \>> > example:
> >> > 
> >> > 
> >> >>> >   newattribute="MyFileSet attribute"/>
> >> > 
> >> >
> >> > 
> >> >>> > newattribute="MyPath attribute"/>
> >> > 
> >>
> >> I assume you meant to write "ant:type" instead of "ant-type"...
> >
> > No...
> > Ant does not have the infrastructure at the moment to support XML
> > namespaces, and their associated contexts.
>
> AFAIK ant _does_ have now the infrastructure to support and use
> XML namespaces.
>
> It is not using it - because we don't know yet what's the best way
> to do it, but AFAIK the infrastructure exists.
>
> ProjectHelper2 uses SAX2, it preserves namespaces in UnknownElement and
> the code for creation of tasks/types (ComponentHelper) receives the
> namespace and the name. CH allows plugins - i.e. any task can hook
> into the component creation and provide it's own mechanism, so you
> should be able to implement whatever namespace policy you want.
>
>
> Costin
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 19523] - zip/unzip should have the capability to use a mapper

2003-05-02 Thread 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=19523

zip/unzip should have the capability to use a mapper





--- Additional Comments From [EMAIL PROTECTED]  2003-05-02 15:20 ---
On further experimentation with my code:
- The mapper part is fine.
- The selector part needs more work. I'll be doing that as soon as I can get 
the Eclipse debugger to work with ant again.

RE: [PATCH] Fix for VAJ4

2003-05-02 Thread Rey Francois 
I have tried Martin's patch and all seems fine. Just one thing: line 56 of
Martin's patch is conflicting with javadoc notation:

+ *JSP Page Compile Generated Code/**, Visual
Age*/**

Should be replaced by

+ *JSP Page Compile Generated Code/**, Visual
Age*/**

Also, I have just added an additional attachment to the bug report ()
containing a final documentation patch that contains both Martin's changes
and mine. Again this is a patch for version 1.5.3, this time made using
"diff -u".

Finally, I suggest to include in the binary release (I guess optional.jar)
the file src\main\org\apache\tools\ant\taskdefs\optional\ide\default.ini so
that people do not have to download the src release to install these tasks.

I think all is set,

Fr.

-Original Message-
From: Martin Landers
To: Ant Developers List
Sent: 2/05/2003 16:05
Subject: Re: [PATCH] Fix for VAJ4


Hi,

[... VAJ Mock classes ...]

> We can use them to compile the VAJ classes that we distribute with
> Ant, but I'm not sure whether we could distribute the mock classes
> themselves.

Hm, AFAIC not distributing the mock classes themselves, only task
binaries
and sources is fine. I just didn't like the idea of people having to
import the complete Ant source into VAJ and back out, just to create the
binaries for the VAJ tasks... (The same thing Francois mentions - the
old
"installation mode" is awful).

> They'll have "ibm" in their names which may be enough to
> make lawyers jump up and down.

Lawyers are a strange kind of people.
I share your concern that the mock classes might cause problems... Which
is why I didn't use the original classes or documentation in creating
the
mock classes and added the disclaimer to each one. But I can't help
about
the names having "com.ibm..." in them, so let's stick with your proposal
and not include the mock classes in the Ant distributions or publicly
available CVS tree. People who have an interest in changing the taks
(that
is need to recompile the binaries) should have VAJ around anyway...

If you feel the Bugzilla attachment may be seen as "distribution", just
remove it.

> As long as we distribute binaries, things should be fine, no?

Yep, I think so. The binaries (and sources) for the tasks only contain
references to the IBM classes, and I hope lawyers don't go crazy for an
"import com.ibm" ;)

cu
Martin

--
{_{__}_}  Martin Landers   [EMAIL PROTECTED]
   oo "elk"[EMAIL PROTECTED]
  / /
 (..) " Who is General Failure and why is he reading my harddisk ? "
  --


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

The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, please notify the sender of this email 
immediately. You should not copy, use or disseminate the 
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.

http://www.capco.com
***

DO NOT REPLY [Bug 17040] - JUnit task report does not use the one defined by setName method

2003-05-02 Thread 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=17040

JUnit task report does not use the one defined by setName method





--- Additional Comments From [EMAIL PROTECTED]  2003-05-02 15:07 ---
OK, I don't get the duplicate elements myself.

endTest will be called twice, obce from formatError and once again at the
end of the test.  It is correct to add the test to failedTests after calling
endTest from formatError as we won't get the  element for it 
otherwise.

DO NOT REPLY [Bug 10016] - VAJ Tasks broken

2003-05-02 Thread 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=10016

VAJ Tasks broken





--- Additional Comments From [EMAIL PROTECTED]  2003-05-02 14:59 ---
Created an attachment (id=6166)
Final doc patch containing changes from Martin L. and F.Rey

DO NOT REPLY [Bug 19449] - broken

2003-05-02 Thread 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=19449

 broken

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-05-02 14:53 ---
should be fixed with nightly build 2003-05-03.

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

2003-05-02 Thread bodewig 
bodewig 2003/05/02 07:50:10

  Modified:src/main/org/apache/tools/ant/taskdefs Zip.java
  Log:
  Improve fix for PR: 19449.
  
  Don't drop directory entries after we've found out they were outdated,
  but simply do not perform timestamp checks on the at all.
  
  Revision  ChangesPath
  1.106 +7 -5  ant/src/main/org/apache/tools/ant/taskdefs/Zip.java
  
  Index: Zip.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Zip.java,v
  retrieving revision 1.105
  retrieving revision 1.106
  diff -u -r1.105 -r1.106
  --- Zip.java  2 May 2003 14:44:53 -   1.105
  +++ Zip.java  2 May 2003 14:50:10 -   1.106
  @@ -807,15 +807,17 @@
   myMapper = gm;
   }
   }
  +
  +Resource[] resources = initialResources[i];
  +if (doFilesonly) {
  +resources = selectFileResources(resources);
  +}
  +
   newerResources[i] = 
   ResourceUtils.selectOutOfDateSources(this,
  - initialResources[i],
  + resources,
myMapper,
getZipScanner());
  -if (doFilesonly) {
  -newerResources[i] = selectFileResources(newerResources[i]);
  -}
  -
   needsUpdate = needsUpdate || (newerResources[i].length > 0);
   
   if (needsUpdate && !doUpdate) {

Re: Roles (was: antlib)

2003-05-02 Thread Costin Manolache 
peter reilly wrote:

\>> > example:
>> > 
>> > 
>> >   > >   newattribute="MyFileSet attribute"/>
>> > 
>> >
>> > 
>> >   > > newattribute="MyPath attribute"/>
>> > 
>>
>> I assume you meant to write "ant:type" instead of "ant-type"...
> 
> No...
> Ant does not have the infrastructure at the moment to support XML
> namespaces, and their associated contexts.

AFAIK ant _does_ have now the infrastructure to support and use 
XML namespaces.

It is not using it - because we don't know yet what's the best way 
to do it, but AFAIK the infrastructure exists.

ProjectHelper2 uses SAX2, it preserves namespaces in UnknownElement and
the code for creation of tasks/types (ComponentHelper) receives the
namespace and the name. CH allows plugins - i.e. any task can hook 
into the component creation and provide it's own mechanism, so you 
should be able to implement whatever namespace policy you want.
 

Costin

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

2003-05-02 Thread bodewig 
bodewig 2003/05/02 07:44:54

  Modified:.WHATSNEW
   src/main/org/apache/tools/ant/taskdefs Zip.java
  Log:
  Don't update archives because it lacks directory entries when we are
  not going to add directory entries either.
  
  PR: 19449
  
  Revision  ChangesPath
  1.408 +3 -0  ant/WHATSNEW
  
  Index: WHATSNEW
  ===
  RCS file: /home/cvs/ant/WHATSNEW,v
  retrieving revision 1.407
  retrieving revision 1.408
  diff -u -r1.407 -r1.408
  --- WHATSNEW  2 May 2003 08:18:36 -   1.407
  +++ WHATSNEW  2 May 2003 14:44:53 -   1.408
  @@ -112,6 +112,9 @@
   * file names that include spaces need to be quoted inside the @argfile
 argument using forked  and JDK 1.4.  Bugzilla Report 10499.
   
  +* Setting filesonly to true in  and related tasks would cause the
  +  archives to be always recreated.  Bugzilla Report 19449.
  +
   Other changes:
   --
   * Six new Clearcase tasks added.
  
  
  
  1.105 +32 -0 ant/src/main/org/apache/tools/ant/taskdefs/Zip.java
  
  Index: Zip.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Zip.java,v
  retrieving revision 1.104
  retrieving revision 1.105
  diff -u -r1.104 -r1.105
  --- Zip.java  18 Apr 2003 22:02:58 -  1.104
  +++ Zip.java  2 May 2003 14:44:53 -   1.105
  @@ -812,6 +812,10 @@
initialResources[i],
myMapper,
getZipScanner());
  +if (doFilesonly) {
  +newerResources[i] = selectFileResources(newerResources[i]);
  +}
  +
   needsUpdate = needsUpdate || (newerResources[i].length > 0);
   
   if (needsUpdate && !doUpdate) {
  @@ -1114,6 +1118,34 @@
   }
   }
   return true;
  +}
  +
  +/**
  + * Drops all non-file resources from the given array.
  + *
  + * @since Ant 1.6
  + */
  +protected Resource[] selectFileResources(Resource[] orig) {
  +if (orig.length == 0) {
  +return orig;
  +}
  +
  +Vector v = new Vector(orig.length);
  +for (int i = 0; i < orig.length; i++) {
  +if (!orig[i].isDirectory()) {
  +v.addElement(orig[i]);
  +} else {
  +log("Ignoring directory " + orig[i].getName() 
  ++ " as only files will be added.", Project.MSG_VERBOSE);
  +}
  +}
  +
  +if (v.size() != orig.length) {
  +Resource[] r = new Resource[v.size()];
  +v.copyInto(r);
  +return r;
  +}
  +return orig;
   }
   
   /**

Re: Roles (was: antlib)

2003-05-02 Thread peter reilly 
For the weblogic stuff, they would surely come
from the same antlib  - say weblogic-ant.jar

using namespace (example for demo purposes only)
   
  
   

 
 
   
   
  

or using prefixes:




 
  
   
   
 
   
   

Granted it would be nice to allow  element to be used in
both the serverdeploy and the ejbjar tasks, but since they do
completely different things, it is not unresonable to say that they
should have different names.

Peter.

On Friday 02 May 2003 14:35, Stefan Bodewig wrote:
> On Wed, 30 Apr 2003, Jose Alberto Fernandez
>
> <[EMAIL PROTECTED]> wrote:
> > The problem you are overlooking is the case of  element
> > in , , , etc.
>
> Maybe not really overlooking but understimating.
>
> The alternative would be to use  and 
> for the different interfaces.  If they come from different antlibs, we
> really should use XML namespaces to resolve this.
>
> But I now understand that having a table per interface may be
> convenient (though not strictly necessary).
>
> Stefan
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs ZipTest.java

2003-05-02 Thread bodewig 
bodewig 2003/05/02 07:24:58

  Modified:src/etc/testcases/taskdefs zip.xml
   src/testcases/org/apache/tools/ant/taskdefs ZipTest.java
  Log:
  Demonstrate bug 19449
  
  Revision  ChangesPath
  1.12  +15 -0 ant/src/etc/testcases/taskdefs/zip.xml
  
  Index: zip.xml
  ===
  RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/zip.xml,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- zip.xml   27 Mar 2003 09:43:48 -  1.11
  +++ zip.xml   2 May 2003 14:24:57 -   1.12
  @@ -102,6 +102,20 @@
   
 
   
  +  
  +  
  +
  +
  +
  +  
  +
  +  
  +  
  +
  +  
  +
 
   
   
  @@ -113,5 +127,6 @@
   
   
   
  +
 
   
  
  
  
  1.14  +10 -0 
ant/src/testcases/org/apache/tools/ant/taskdefs/ZipTest.java
  
  Index: ZipTest.java
  ===
  RCS file: 
/home/cvs/ant/src/testcases/org/apache/tools/ant/taskdefs/ZipTest.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- ZipTest.java  27 Mar 2003 09:43:49 -  1.13
  +++ ZipTest.java  2 May 2003 14:24:58 -   1.14
  @@ -144,4 +144,14 @@
   ZipEntry ze = zf.getEntry("test/");
   assertNotNull("test/ has been added", ze);
   }
  +
  +// Bugzilla Report 19449
  +public void testFilesOnlyDoesntCauseRecreate() 
  +throws InterruptedException {
  +executeTarget("testFilesOnlyDoesntCauseRecreateSetup");
  +long l = getProject().resolveFile("test3.zip").lastModified();
  +Thread.currentThread().sleep(3000);
  +executeTarget("testFilesOnlyDoesntCauseRecreate");
  +assertEquals(l, 
getProject().resolveFile("test3.zip").lastModified());
  +}
   }

Re: [PATCH] Fix for VAJ4

2003-05-02 Thread Martin Landers 

Hi,

[... VAJ Mock classes ...]

> We can use them to compile the VAJ classes that we distribute with
> Ant, but I'm not sure whether we could distribute the mock classes
> themselves.

Hm, AFAIC not distributing the mock classes themselves, only task binaries
and sources is fine. I just didn't like the idea of people having to
import the complete Ant source into VAJ and back out, just to create the
binaries for the VAJ tasks... (The same thing Francois mentions - the old
"installation mode" is awful).

> They'll have "ibm" in their names which may be enough to
> make lawyers jump up and down.

Lawyers are a strange kind of people.
I share your concern that the mock classes might cause problems... Which
is why I didn't use the original classes or documentation in creating the
mock classes and added the disclaimer to each one. But I can't help about
the names having "com.ibm..." in them, so let's stick with your proposal
and not include the mock classes in the Ant distributions or publicly
available CVS tree. People who have an interest in changing the taks (that
is need to recompile the binaries) should have VAJ around anyway...

If you feel the Bugzilla attachment may be seen as "distribution", just
remove it.

> As long as we distribute binaries, things should be fine, no?

Yep, I think so. The binaries (and sources) for the tasks only contain
references to the IBM classes, and I hope lawyers don't go crazy for an
"import com.ibm" ;)

cu
Martin

--
{_{__}_}  Martin Landers   [EMAIL PROTECTED]
   oo "elk"[EMAIL PROTECTED]
  / /
 (..) " Who is General Failure and why is he reading my harddisk ? "
  --

Re: Roles (was: antlib)

2003-05-02 Thread Stefan Bodewig 
On Wed, 30 Apr 2003, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:

> The problem you are overlooking is the case of  element
> in , , , etc.

Maybe not really overlooking but understimating.

The alternative would be to use  and 
for the different interfaces.  If they come from different antlibs, we
really should use XML namespaces to resolve this.

But I now understand that having a table per interface may be
convenient (though not strictly necessary).

Stefan

DO NOT REPLY [Bug 19523] - zip/unzip should have the capability to use a mapper

2003-05-02 Thread 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=19523

zip/unzip should have the capability to use a mapper





--- Additional Comments From [EMAIL PROTECTED]  2003-05-02 13:36 ---
Thanks Peter for the clairification... I appreciate your feedback.  I think 
that your solution will work fine for me, since I only need a single mapper.

But, as you correctly point out, it would be far more elegant for filesets to 
also support mappers.  Plus, I'm sure that using nested mappers inside filesets 
will be useful in tasks other than zip.

Thanks again.

Re: [PATCH] Fix for VAJ4

2003-05-02 Thread Stefan Bodewig 
On Fri, 2 May 2003, Martin Landers <[EMAIL PROTECTED]> wrote:

>  When committing my patches (maybe after Francois has verified they
>  work for him), could you also submit the patches for
>  (VAJAntTool.html) from Francois?

Sure.  And no need to rush things.  I won't get to it today and I
usually don't touch my keyboard at weekends.

>> 1. Come up with mock classes (same interface, no-op methods)
> 
> Yep, this is my favourite too.

We can use them to compile the VAJ classes that we distribute with
Ant, but I'm not sure whether we could distribute the mock classes
themselves.  They'll have "ibm" in their names which may be enough to
make lawyers jump up and down.

As long as we distribute binaries, things should be fine, no?

Stefan

DO NOT REPLY [Bug 10016] - VAJ Tasks broken

2003-05-02 Thread 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=10016

VAJ Tasks broken





--- Additional Comments From [EMAIL PROTECTED]  2003-05-02 13:07 ---
Created an attachment (id=6159)
Mockups of the VAJ classes needed to compile the tasks.

RE: [PATCH] Fix for VAJ4

2003-05-02 Thread Martin Landers 

Hi Folks,

Francois: Don't bother writing mock classes, I've done so already. I'll
attach the jar-File to the Bug-Report. (Hope you haven't started yet...)

> Perhaps the only useful thing from my patch is an update of the
> installation steps (VAJAntTool.html): if we have compiled classes
> distributed with Ant, why bother with importing Ant and Xerces in VAJ?

Great you've update that part of the documentation (which I didn't).

> I propose the following:
> - I try  Martin's patch on my environment (VAJ 4.0 on NT4)
> - Martin: can you see if my documentation patch to the installation
> procedure also works on your side?

Sounds good!

 I'll check your documentation when I come back to work (where I have
access to VAJ) on Monday, but I guess it's going to be fine. Stefan: When
committing my patches (maybe after Francois has verified they work for
him), could you also submit the patches for (VAJAntTool.html)  from
Francois?

> Regarding the distribution, Martin proposed 3 options for resolving the
> issue of using the VAJ servlet classes (which are not distributed with Ant):
>1. Come up with mock classes (same interface,
>   no-op methods) to make the compiler happy and
>   use them during the build (I'd prefer this way)
[...]

Yep, this is my favourite too. I've written up mock versions of the
classes (empty method bodies returning null, false, etc.) that the tasks
compile against - I've already sent them to Stefan directly, and will
attach them to the bugzilla report.

> I'd be tempted to include the .class files from VAJ, however I'm not sure if
> that is really permitted... It's probably safer to go with option 1 so that
> the build process keeps working. I'll make those mockups and check if the
> compiled classes still work.

How about checking (and correcting) my mock classes instead :)  (I'm not
100% sure about return types, as I've written the classes from compiler
errors, not looking at the original classes - kind of a cleanroom
implementation... ). Additionally I've added a small disclaimer in each
class stating "It's not the ASF's fault"  basically - someone might want
to check this before putting the JAR to CVS...

cu
Martin

--
{_{__}_}  Martin Landers   [EMAIL PROTECTED]
   oo "elk"[EMAIL PROTECTED]
  / /
 (..) " Who is General Failure and why is he reading my harddisk ? "
  --

Re: Roles (was: antlib)

2003-05-02 Thread peter reilly 
On Friday 02 May 2003 11:46, Wannheden, Knut wrote:
> Peter,
>
> > example:
> > 
> > 
> >>   newattribute="MyFileSet attribute"/>
> > 
> >
> > 
> >> newattribute="MyPath attribute"/>
> > 
>
> I assume you meant to write "ant:type" instead of "ant-type"...

No...
Ant does not have the infrastructure at the moment to support XML
namespaces, and their associated contexts.

>
> I suppose in both examples all further attributes are for the target class.
> E.g. both attributes "dir" and "newattribute" are for .

Yes, however myfileset has to extend the 's 
introspected class.

>  Or
> would the "dir" attribute be required for types of 's 
> role?
Yes,  as myfileset extends copies fileset elements's class it
inherites all the attributes and nested elements. It may however
override the implementation and throw a not supported exception for
specific attributes/nested elements.

for example:

public static class MyFileSet
extends FileSet
{
public void setNewAttribute(String value) {
System.out.println("My fileset " + value);
}
public void setFollowSymlinks(boolean ignored) {
throw new BuildException(
"Symbolic links not supported");
}
}

Peter.

RE: Roles (was: antlib)

2003-05-02 Thread Wannheden, Knut 
Peter,

> 
> example:
> 
> 
>  newattribute="MyFileSet attribute"/>
> 
> 
> 
>newattribute="MyPath attribute"/>
> 
> 

I assume you meant to write "ant:type" instead of "ant-type"...

I suppose in both examples all further attributes are for the target class.
E.g. both attributes "dir" and "newattribute" are for .  Or
would the "dir" attribute be required for types of 's 
role?

--
knut

Re: Roles (was: antlib)

2003-05-02 Thread peter reilly 
I have done a little further work on my patch
to allow nested elements to have Project type
as a constructor.

If the object contains both add() and create(),
the add() method is used.

example:


  



  


I will upload the modified  patch over the weekend.

Peter

On Friday 02 May 2003 10:07, Stefan Bodewig wrote:
> On Wed, 30 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
> > Can you explain again what's wrong with create ? I think I missed
> > it...
>
> You can't pass in a subclass of the type returned by the createXYZ
> method as the object creation happens inside the task.  If you want to
> use a subclass of Path named mypath, you can't use it in tasks that
> use createPath for the nested  element.
>
> > My understanding was that whatever is in use today will continue to
> > work the same, we just add a new pattern at the end.
>
> Yes, with the caveat that polymorphism doesn't work for the createXYZ
> case.
>
> Stefan
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

RE: [PATCH] Fix for VAJ4

2003-05-02 Thread Rey Francois 
I have sumbmitted my patch to Bugzilla
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10016). There is another
patch attached to this bug (from Martin Landers), which fixes the same issue
as mine, but includes other improvements as well. So let's take Martin's
patch since it includes more. Perhaps the only useful thing from my patch is
an update of the installation steps (VAJAntTool.html): if we have compiled
classes distributed with Ant, why bother with importing Ant and Xerces in
VAJ?
I propose the following:
- I try  Martin's patch on my environment (VAJ 4.0 on NT4)
- Martin: can you see if my documentation patch to the installation
procedure also works on your side?

Regarding the distribution, Martin proposed 3 options for resolving the
issue of using the VAJ servlet classes (which are not distributed with Ant):
   1. Come up with mock classes (same interface,
  no-op methods) to make the compiler happy and
  use them during the build (I'd prefer this way)
   2. Ship compiled .class files supplied by someone
  that has VAJ available
  (I'd be willing to do that _for this version_)
   3. Leave it alone and let people figure it out...
  (surely the easiest way, but probably gives a
   few people - like me - a hard time...)
I'd be tempted to include the .class files from VAJ, however I'm not sure if
that is really permitted... It's probably safer to go with option 1 so that
the build process keeps working. I'll make those mockups and check if the
compiled classes still work.

Fr.

-Original Message-
From: Stefan Bodewig
To: [EMAIL PROTECTED]
Sent: 2/05/2003 8:21
Subject: Re: [PATCH] Fix for VAJ4

On Wed, 30 Apr 2003, Rey Francois <[EMAIL PROTECTED]> wrote:

> - I used "diff -c" to create them (the -u option is not available on
> my platform).

Either a strange platform or a strange implementation of diff.
context diffs should work as good as unified diffs.

> In any case I also included the modified files.

No.  Maybe they've been stripped of by the mailing list software,
which doesn't like HTML (which is good IMHO).  Could you please attach
the patch to 
so that we collect them in a single place?

I'm also going to add Martin's patches there.

Feel free to add yourself to the CC list of this report as well.

Stefan

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


The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, please notify the sender of this email 
immediately. You should not copy, use or disseminate the 
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.

http://www.capco.com
***

Re: Roles (was: antlib)

2003-05-02 Thread Stefan Bodewig 
On Wed, 30 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:

> Can you explain again what's wrong with create ? I think I missed
> it...

You can't pass in a subclass of the type returned by the createXYZ
method as the object creation happens inside the task.  If you want to
use a subclass of Path named mypath, you can't use it in tasks that
use createPath for the nested  element.

> My understanding was that whatever is in use today will continue to
> work the same, we just add a new pattern at the end.

Yes, with the caveat that polymorphism doesn't work for the createXYZ
case.

Stefan

Re: Roles (was: antlib)

2003-05-02 Thread Stefan Bodewig 
On Wed, 30 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
> Stefan Bodewig wrote:
>  
>> I don't see a need for separate namespaces depending on the
>> interfaces, so only using the child's element name (and namespace)
>> could be enough.  I'm not sure whether I'm overlooking a problem.
> 
> Not sure I understand.  Namespaces are not required to solve the
> polymorphism problem.

Me neither, two overloaded meanings for "namespace".  Let me try to
rephrase:

I don't see the need for a different mapping of names to classes
depending on the interface, one mapping should be enough.  This would
mean the child's element name (and XML namespace) should suffice and
we don't need the interface the child is expected to implement to
determine the class.

> My concern was the API used by ComponentHelper - I would rather 
> add the "parent" parameter, even if it's not used now, if we expect
> we'll find some use cases that will require it ( say in 1.7+ ).

OK.

>> An alternative to a magic namespace would be magic attribute names.
>> We can use attributes that contain dashes
>> 
>> 
>>   
>> 
>> 
>> use-as quite clearly states the user's intent and it is impossible
>> to have an existing attribute for tasks or nested elements.
> 
> Sounds good ( not "use-as", but magic attribute ). Maybe "ant:type"
> would be better ?

This introduces a magic attribute name and a magic namespace.  Works
for me.

> The attribute should be optional

Of course.

Stefan

DO NOT REPLY [Bug 18884] - stcheckout should handle a convertCRLF flag

2003-05-02 Thread 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=18884

stcheckout should handle a convertCRLF flag

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-05-02 08:21 ---
Thanks, patch will be in nightly build 2003-05-03.

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam StarTeamCheckout.java

2003-05-02 Thread bodewig 
bodewig 2003/05/02 01:18:37

  Modified:.WHATSNEW
   docs/manual/OptionalTasks starteam.html
   src/main/org/apache/tools/ant/taskdefs/optional/starteam
StarTeamCheckout.java
  Log:
  Provide control over EOL conversion via a new attribute.
  
  PR: 18884
  Submitted by: Steve Cohen 
  Aaron DeForest 
  
  Revision  ChangesPath
  1.407 +4 -0  ant/WHATSNEW
  
  Index: WHATSNEW
  ===
  RCS file: /home/cvs/ant/WHATSNEW,v
  retrieving revision 1.406
  retrieving revision 1.407
  diff -u -r1.406 -r1.407
  --- WHATSNEW  29 Apr 2003 13:16:22 -  1.406
  +++ WHATSNEW  2 May 2003 08:18:36 -   1.407
  @@ -279,6 +279,10 @@
   *  will now detect and successfully extract self-extracting
 archives.  Bugzilla Report 16213.
   
  +*  has a new attribute "converteol" that can be used to
  +  control the automatic line-end conversion performed on ASCII files.
  +  Bugzilla Report 18884.
  +
   Changes from Ant 1.5.2 to Ant 1.5.3
   ===
   
  
  
  
  1.19  +10 -0 ant/docs/manual/OptionalTasks/starteam.html
  
  Index: starteam.html
  ===
  RCS file: /home/cvs/ant/docs/manual/OptionalTasks/starteam.html,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- starteam.html 22 Apr 2003 07:35:15 -  1.18
  +++ starteam.html 2 May 2003 08:18:36 -   1.19
  @@ -176,6 +176,16 @@
   yes
 
   
  +  
  +convertEOL
  +If true, (default) all ascii files will have their 
end-of-line 
  +characters adjusted to that of the local machine on checkout.  This is 
normally
  +what you'd want but if for some reason you don't want that to happen, 
set it to false
  +and the files will be checked out with whatever end-of-line characters 
are used on
  +the server. 
  +yes
  +  
  +
   
   
   Examples
  
  
  
  1.18  +28 -4 
ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam/StarTeamCheckout.java
  
  Index: StarTeamCheckout.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam/StarTeamCheckout.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- StarTeamCheckout.java 18 Apr 2003 23:40:28 -  1.17
  +++ StarTeamCheckout.java 2 May 2003 08:18:36 -   1.18
  @@ -99,6 +99,14 @@
   private boolean deleteUncontrolled = true;
   
   /**
  + * holder for the deleteUncontrolled attribute.  If true,
  + * (default) local non-binary files will be checked out using the local 
  + * platform's EOL convention.  If false, checkouts will preserve the
  + * server's EOL convention.
  + */
  +private boolean convertEOL = true;
  +
  +/**
* flag (defaults to true) to create all directories
* that are in the Starteam repository even if they are empty.
*
  @@ -118,6 +126,16 @@
   }
   
   /**
  + * Set whether or not files should be checked out using the
  + * local machine's EOL convention.
  + * Optional, defaults to true.
  + * @param value  the value to set the attribute to.
  + */
  +public void setConvertEOL(boolean value) {
  +this.convertEOL = value;
  +}
  +
  +/**
* Sets the label StarTeam is to use for checkout; defaults to the most 
recent file.
* The label must exist in starteam or an exception will be thrown. 
* @param label the label to be used
  @@ -277,7 +295,8 @@
   log("  Items will be checked out with Exclusive locks.");
   }
   else if (this.lockStatus == Item.LockType.UNLOCKED) {
  -log("  Items will be checked out unlocked (even if presently 
locked).");
  +log("  Items will be checked out unlocked "
  + +"(even if presently locked).");
   } 
   else {
   log("  Items will be checked out with no change in lock 
status.");
  @@ -291,9 +310,14 @@
   if (this.deleteUncontrolled) {
   log("  Local items not found in the repository will be 
deleted.");
   }
  +log("  Items will be checked out " +
  +(this.convertEOL 
  + ? "using the local machine's EOL convention"
  + : "without changing the EOL convention used on the server"));
   log("  Directories will be created"+
  -(this.createDirs ? " wherever they exist in the repository, even 
if empty." 
  - : " only where needed to check out files."));
  +(this.createDirs 
  + ? " wherever they exist in the repository, even if empty." 
  + : " only where needed to check out

DO NOT REPLY [Bug 19541] - New RExec optional task

2003-05-02 Thread 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=19541

New RExec optional task





--- Additional Comments From [EMAIL PROTECTED]  2003-05-02 07:11 ---
Created an attachment (id=6155)
Zip of patch and modified files

DO NOT REPLY [Bug 19541] New: - New RExec optional task

2003-05-02 Thread 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=19541

New RExec optional task

   Summary: New RExec optional task
   Product: Ant
   Version: 1.5.3
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have implemented a new RExecTask which I believe can be of use to others. I 
wasn't that difficult: I took the TelnetTask as a model and transformed it into 
an RExecTask.

Note: 
- these patches have been made against Ant 1.5.3 
- I used "diff -c" to create them (the -u option is not available on my 
platform). In any case I also included the modified files.

- the new task also makes use of the NetComponents 
(http://www.savarese.org/oro/downloads/index.html#NetComponents). 

Enjoy, 

Fr.

DO NOT REPLY [Bug 10016] - VAJ Tasks broken

2003-05-02 Thread 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=10016

VAJ Tasks broken





--- Additional Comments From [EMAIL PROTECTED]  2003-05-02 07:05 ---
Created an attachment (id=6154)
zip of patch and modified files

DO NOT REPLY [Bug 10016] - VAJ Tasks broken

2003-05-02 Thread 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=10016

VAJ Tasks broken





--- Additional Comments From [EMAIL PROTECTED]  2003-05-02 06:26 ---
Created an attachment (id=6152)
Patchset by Martin Landers, see also 
http://marc.theaimsgroup.com/?l=ant-dev&m=104274373314550&w=2

Re: [PATCH] Fix for VAJ4

2003-05-02 Thread Stefan Bodewig 
On Wed, 30 Apr 2003, Rey Francois <[EMAIL PROTECTED]> wrote:

> - I used "diff -c" to create them (the -u option is not available on
> my platform).

Either a strange platform or a strange implementation of diff.
context diffs should work as good as unified diffs.

> In any case I also included the modified files.

No.  Maybe they've been stripped of by the mailing list software,
which doesn't like HTML (which is good IMHO).  Could you please attach
the patch to 
so that we collect them in a single place?

I'm also going to add Martin's patches there.

Feel free to add yourself to the CC list of this report as well.

Stefan

DO NOT REPLY [Bug 10016] - VAJ Tasks broken

2003-05-02 Thread 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=10016

VAJ Tasks broken

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
 AssignedTo|[EMAIL PROTECTED]  |[EMAIL PROTECTED]
   Target Milestone|--- |1.6

Re: [PATCH] Fix for VAJ4

2003-05-02 Thread Stefan Bodewig 
On Wed, 30 Apr 2003, Martin Landers <[EMAIL PROTECTED]> wrote:

> Stefan: I think we've found someone to confirm my patches! :)

Yep, I've seen it. 8-)

> I propose that Stefan (or another willing committer ;) gets the
> patches into the Ant 1.6 branch

Looks as if we had a plan.  I'm going to assign the bugzilla reports
to myself and if I find issues, we will sort them out there.

> (if there are any problems - I think my patches were against post
> 1.5.1 CVS HEAD

There shouldn't be too many problems as the code probably hasn't
changed at all except for cosmetics.

> - contact me)

Will do.

> (Making we wonder if they ever worked at all

Same here.

Stefan

DO NOT REPLY [Bug 19536] - JUnitReport Report Fails

2003-05-02 Thread 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=19536

JUnitReport Report Fails





--- Additional Comments From [EMAIL PROTECTED]  2003-05-02 02:59 ---
Looks like you have multiple versions of Xalan on your classpath. Possibly the
one included with the JDK, and the one you have placed in $ANT_HOME/lib

I would recomend having nothing in your classpath, use Ant's 
elements to build the classpath used by 

For  to work, (using user supplied libraries, not the JDK ones)
your $ANT_HOME/lib should contain ant.jar, optional.jar, junit,jar,
xml-apis.jar, xercesImpl.jar and xalan.jar

You can run 'ant -diagnostics' to see what versions are being used.

I would also suggest posting this type of problem to the ant-user mailing list,
rather than using bugzilla.

Jesse

DO NOT REPLY [Bug 19536] New: - JUnitReport Report Fails

2003-05-02 Thread 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=19536

JUnitReport Report Fails

   Summary: JUnitReport Report Fails
   Product: Ant
   Version: 1.5.3
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Major
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Okay, I am at my wits end.  I think there is a bug in with the JUnitReport.  

I’ve downloaded the latest version of the following programs

 J2SE 1.4.0_01
 Ant 1.5.3
 JUnit 3.8.1, and 
 Xalan 2.5.0

I have moved all the Xalan and JUnit .jar files into the ant/lib directory.  
Thus, the only original .jar files in the ant/lib directory are the ant.jar 
and optional.jar files.

My classpath looks like this:
CLASSPATH=;C:\Development\Java\JDK-141\lib\tools.jar;
   C:\Development\Java\JDK-141\lib\dt.jar;
   C:\Development\Java\J2EE-131\lib\j2ee.jar;
   C:\Development\Java\J2EE-131\lib\j2eetools.jar;
   C:\Development\Java\J2EE-131\lib\jhall.jar;
   C:\Development\Java\JacORB_1_4_1\lib\idl.jar;
   C:\Development\Java\JacORB_1_4_1\lib\jacorb.jar

My path looks lilke this:
PATH=;C:\WINDOWS;
  C:\WINDOWS\system32;
  C:\WINDOWS\System32\Wbem;
  C:\Development\Java\JDK-141\bin;
  C:\Development\Java\JacORB_1_4_1\bin;
  C:\Development\Java\Jakarta\Ant\bin;
  C:\Development\Java\JEdit;

When I get to the part of the JUnitReport task which says:



It blows up every time.  The printout below shows the output.
If I comment this line out the task will run.  Of course, it does not produce 
any output, but it does single out this line as the culprit.  

One thing which has me worried is the second line of the JUnitReport.

   [junitreport] Using Xalan version: Xalan Java 2.2.D11

I downloaded 2.5 so I don't know where it's getting 2.2 from.  I deleted all 
xal*.jar files (except for the ant/lib) from my system.

I just don’t know what I could be doing wrong?  Consequently, I am guessing 
it's a bug.


Printout below…
__


C:\Consulting\e-ccconsulting\CTI-Component>ant -verbose junit-run
Apache Ant version 1.5.3 compiled on April 16 2003
Buildfile: build.xml
Detected Java version: 1.4 in: C:\Development\Java\JDK-141\jre
Detected OS: Windows XP
parsing buildfile build.xml with URI = file:C:/Consulting/e-ccconsulting/CTI-
Component/build.xml
Project base dir set to: C:\Consulting\e-ccconsulting\CTI-Component
 [property] Loading C:\Consulting\e-ccconsulting\CTI-Component\build.properties
Override ignored for property build.compiler.debug
Override ignored for property build.compiler.verbose
Override ignored for property build.compiler.deprecation
Override ignored for property build.compiler.optimize
Build sequence for target `junit-run' is [init, junit-run]
Complete build sequence is [init, junit-run, all, compile-common, compile-
tests, clean-all, dist]

init:
 [echo] ---
 [echo] --  Project:  Citicorp Call Center Enhancements
 [echo] --   Module:  CTI Interface Component
 [echo]
 [echo]
 [echo] --Owner:  e-CC Development Services,Inc.
 [echo]   Copyright 2003
 [echo]   All Rights Reserved
 [echo]
 [echo] ---
 [echo]
 [echo]Application: CTI_Component
 [echo]   Java Version: 1.4
 [echo]Ant Version: Apache Ant version 1.5.3 compiled on April 16 2003
 [echo]   Build Number: 147
 [echo]
 [echo]   Base Dir: C:\Consulting\e-ccconsulting\CTI-Component
 [echo]   Target Build: C:\Consulting\e-ccconsulting\CTI-Component/build
 [echo]   Dest Dir: C:\Consulting\e-ccconsulting\CTI-
Component/build/classes
 [echo]webapps dir: C:\Consulting\e-ccconsulting\CTI-
Component/build/webapps
 [echo]Lib Dir: C:\Consulting\e-ccconsulting\CTI-Component/lib

 [echo]  classpath: C:\Development\Java\JDK-141
\lib\tools.jar;C:\Development\Java\Jakarta\Ant\lib\xsltcservlet.jar;C:\Develo
pment\Java\Jakarta\Ant\lib\xsltcejb.jar;C:\Development\Java\Jakarta\Ant\lib\xsl
tcbrazil.jar;C:\Development\Java\Jakarta\Ant\lib\xslt
capplet.jar;C:\Development\Java\Jakarta\Ant\lib\xml-
apis.jar;C:\Development\Java\Jakarta\Ant\lib\xercesImpl.jar;C:\Development\Java
\
Jakarta\Ant\lib\xalansamples.jar;C:\Development\Java\Jakarta\Ant\lib\xalan.jar;
C:\Development\Java\Jakarta\Ant\lib\optional.jar;C:\D
evelopment\Java\Jakarta\Ant\lib\junit.jar;C:\Development\Java\Jakarta\Ant\lib\b
sf.jar;C:\Development\J

DO NOT REPLY [Bug 19523] - zip/unzip should have the capability to use a mapper

2003-05-02 Thread 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=19523

zip/unzip should have the capability to use a mapper





--- Additional Comments From [EMAIL PROTECTED]  2003-05-02 01:07 ---
Simon,
Let me explain. The only reason I marked your request as a duplicate of mine 
(and not the other way around, as would have been natural) is because I have 
expanded on the original by adding a request for zip to honor selectors and I 
was afraid that this would get lost. Sorry, I know that this procedure was 
less than polite. 

In addition, I have provided an implementation of both features, so I am 
hoping that this way there is more of a chance that our requests will get into 
the codebase. 

If you wan't to try out my code, here is what you have to do:
1. Get the source.
2. Copy the class org.apache.tools.ant.taskdefs.Zip to a package of your own.
3. Fix the baseclass reference by importing it.
4. Replace the method addResources with the one I have supplied.
5. Add the rest of the code I have supplied to the class.
6. Compile it and place it in a jar, say ext.jar
7. In your build file add 
8. Use  instead of . You can now use this with a mapper as 
in your example.

I had to use this technique instead of extending the original Zip task because 
the key method (addResources) is final.

On second examination your request may require a little more work, because the 
nested filesets would have to allow mapper. My version is simpler, the 
question is would that satisfy you? In my version there can be only one mapper 
per zip being built, in your version one could use several filesets, each with 
its own mapper, so it is more general. However, in practice, allowing only the 
single mapper, the same result can be achieved by using more than one zip task 
and spcifying update="yes" on all but the first. This of course is less 
elegant than having multiple mappers.