DO NOT REPLY [Bug 17901] New: - option to create user defined project class instance

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

option to create user defined project class instance

   Summary: option to create user defined project class instance
   Product: Ant
   Version: 1.6Alpha (nightly)
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I needed to derive my own class from Project.  This was fine as long as my code
created the project instance but when I wanted to use the antcall task, there
was no way to tell ant to use my class instead of the default since the code
that creates the project instance uses a hardcoded class name.

DO NOT REPLY [Bug 17901] - option to create user defined project class instance

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

option to create user defined project class instance





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 00:36 ---
Created an attachment (id=5278)
patch to allow user to specify project class via cmd line option

Re: enhanced pvcs task for PVCS version 7.5

[Martin]

Herr Periyaswamy:

I  believe the procedure is you would have to gain approval of at least one
of the commiters
(There is also the question of who would maintain it for the next version of
PVCS)
In any case could you repost the code for all to see.
Vielen Danke,
Martin

Gesellschaftlich ist kaum etwas so erfolgreich wie Dummheit mit guten
Manieren.
Voltaire

- Original Message -
From: <[EMAIL PROTECTED]>
To: "Ant Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, March 11, 2003 4:28 PM
Subject: RE: enhanced pvcs task for PVCS version 7.5


>
> 
> I'd be interested in it, although I am a firm believer in maintaining
> compatibility with old-style get.
> 
> I agree. Please take a look at the source, I attached to the other reply,
> but that is in no way complete. I just wanted it to work for our PVCS vm
> version. As you have mentioned, it could be modified to be in compatible
> with older versions.
>
> Chandra Periyaswamy
>
>
>
>
>   "Steven Newton"
>   <[EMAIL PROTECTED]To:   "Ant Developers
List" <[EMAIL PROTECTED]>
>   .com>cc:
>Subject:  RE: enhanced pvcs
task for PVCS version 7.5
>   03/11/2003 05:08
>   PM
>   Please respond to
>   "Ant Developers
>   List"
>
>
>
>
>
>
> I'd be interested in it, although I am a firm believer in maintaining
> compatibility with old-style get.  A question for the Ant Powers That
> Be:
> What's the recommended way to do this sort of migration? Create a new
> task that's similar to the old but includes the enhancements, or add
> options to the new task that default to the old behavior?  What about if
> the change can not be backwards-compatible -- would that favor the
> creation of a new "enhanced" task?  I'm thinking here of the issues
> around http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13847.
>
> s
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 11, 2003 12:14 PM
> To: [EMAIL PROTECTED]
> Subject: enhanced pvcs task for PVCS version 7.5
>
>
> Hi,
>
> I'm a greenhorn to this list, so please pardon my mistakes if any.
>
> I modified the pvcs task to work with PVCS VM version 7.5. Instead of a
> old
> "get", I use "pcli get" in this modified version. It has been tested and
> used in my project. I have tested on sun OS. I would be glad to submit
> the
> source, if you'd like. Please let me know what you think.
>
> I also think keeping the support for the old "get" may also seem
> important
> for the community.
>
>
> :o) Chandra Periyaswamy
>
>
>
>
> -
> 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: ssh exec task...

[Stefan Bodewig]

On Tue, 11 Mar 2003, Rob H. Anderson <[EMAIL PROTECTED]>
wrote:

> Attached is the documentation.

No it isn't (no HTML parts on our list, even attachments).  Could you
either send it to me directly or simply zip it up before attaching it?

> I wonder if there is anyway to wait for the thread to finnish?

So do I.  I played with reading from the outputstream (much like the
StreamPumper stuff in ) in the hope the IO would block, but have
no good results so far.

I'll try to understand the inner workings of jsch (though my time is a
bit limited ATM) and ask on jsch-users if all else fails.  You are
invited to do some research of your own, of course 8-)

> Does this mean that ant will report "Build Successfull" before the
> command has actually completed (Yuk)?

Potentially.

Stefan

DO NOT REPLY [Bug 17780] - Instead of updating a jar file, the task overrides it.

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

Instead of updating a jar file, the task overrides it.

[EMAIL PROTECTED] changed:

   What|Removed |Added

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

DO NOT REPLY [Bug 17883] - Custom task containers don't share property state across subtasks

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

Custom task containers don't share property state across subtasks





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 09:50 ---
Take a look at how  solves that.  The key is overriding 
maybeConfigure.

I completely agree that this needs to be documented.

DO NOT REPLY [Bug 17780] - Instead of updating a jar file, the task overrides it.

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

Instead of updating a jar file, the task overrides it.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

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

[bodewig]

bodewig 2003/03/12 02:19:59

  Modified:src/etc/testcases/taskdefs jar.xml
   src/testcases/org/apache/tools/ant/taskdefs JarTest.java
  Log:
  currently failing testcase to demonstrate PR: 17780
  
  Revision  ChangesPath
  1.10  +11 -0 ant/src/etc/testcases/taskdefs/jar.xml
  
  Index: jar.xml
  ===
  RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/jar.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- jar.xml   26 Feb 2003 09:57:01 -  1.9
  +++ jar.xml   12 Mar 2003 10:19:59 -  1.10
  @@ -189,4 +189,15 @@
   
 
   
  +  
  +  
  +
  +  
  +
  +  
  +
  +
  +
  +  
   
  
  
  
  1.19  +9 -2  
ant/src/testcases/org/apache/tools/ant/taskdefs/JarTest.java
  
  Index: JarTest.java
  ===
  RCS file: 
/home/cvs/ant/src/testcases/org/apache/tools/ant/taskdefs/JarTest.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- JarTest.java  26 Feb 2003 09:57:01 -  1.18
  +++ JarTest.java  12 Mar 2003 10:19:59 -  1.19
  @@ -67,6 +67,7 @@
   public class JarTest extends BuildFileTest {
   
   private static String tempJar = "tmp.jar";
  +private static String tempDir = "jartmp/";
   private Reader r1, r2;
   
   public JarTest(String name) {
  @@ -170,9 +171,9 @@
   executeTarget("testManifestStaysIntact");
   
   r1 = new FileReader(getProject()
  -.resolveFile("jartmp/manifest"));
  +.resolveFile(tempDir + "manifest"));
   r2 = new FileReader(getProject()
  -.resolveFile("jartmp/META-INF/MANIFEST.MF"));
  +.resolveFile(tempDir + "META-INF/MANIFEST.MF"));
   Manifest mf1 = new Manifest(r1);
   Manifest mf2 = new Manifest(r2);
   assertEquals(mf1, mf2);
  @@ -218,5 +219,11 @@
   executeTarget("testCreateWithEmptyFilesetSetUp");
   executeTarget("testCreateWithEmptyFileset");
   executeTarget("testCreateWithEmptyFileset");
  +}
  +
  +public void testUpdateIfOnlyManifestHasChanged() {
  +executeTarget("testUpdateIfOnlyManifestHasChanged");
  +File jarXml = getProject().resolveFile(tempDir + "jar.xml");
  +assertTrue(jarXml.exists());
   }
   }
  
  
  

dev-unsubscribe@ant.apache.org

[ckny]

"Ant Developers List" <[EMAIL PROTECTED]> schrieb am 12.03.03 09:35:17:
> 
> On Tue, 11 Mar 2003, Rob H. Anderson <[EMAIL PROTECTED]>
> wrote:
> 
> > Attached is the documentation.
> 
> No it isn't (no HTML parts on our list, even attachments).  Could you
> either send it to me directly or simply zip it up before attaching it?
> 
> > I wonder if there is anyway to wait for the thread to finnish?
> 
> So do I.  I played with reading from the outputstream (much like the
> StreamPumper stuff in ) in the hope the IO would block, but have
> no good results so far.
> 
> I'll try to understand the inner workings of jsch (though my time is a
> bit limited ATM) and ask on jsch-users if all else fails.  You are
> invited to do some research of your own, of course 8-)
> 
> > Does this mean that ant will report "Build Successfull" before the
> > command has actually completed (Yuk)?
> 
> Potentially.
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Erster Klick - SMS versenden, zweiter Klick - die Telefonnummer im 
Adressbuch speichern bei: http://freemail.web.de/features/?mc=021151

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

[bodewig]

bodewig 2003/03/12 03:23:28

  Modified:src/main/org/apache/tools/ant/taskdefs Jar.java Zip.java
  Log:
  Fix the bug.
  
  PR: 17780
  
  Revision  ChangesPath
  1.71  +5 -3  ant/src/main/org/apache/tools/ant/taskdefs/Jar.java
  
  Index: Jar.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Jar.java,v
  retrieving revision 1.70
  retrieving revision 1.71
  diff -u -r1.70 -r1.71
  --- Jar.java  17 Feb 2003 14:00:34 -  1.70
  +++ Jar.java  12 Mar 2003 11:23:27 -  1.71
  @@ -531,11 +531,12 @@
* out-of-date.  Subclasses overriding this method are supposed to
* set this value correctly in their call to
* super.getResourcesToAdd.
  - * @return an array of resources to add for each fileset passed in.
  + * @return an array of resources to add for each fileset passed in as 
well
  + * as a flag that indicates whether the archive is uptodate.
*
* @exception BuildException if it likes
*/
  -protected Resource[][] getResourcesToAdd(FileSet[] filesets,
  +protected ArchiveState getResourcesToAdd(FileSet[] filesets,
File zipFile,
boolean needsUpdate)
   throws BuildException {
  @@ -581,7 +582,8 @@
   
   ZipOutputStream zOut = null;
   try {
  -log("Building jar: " + getDestFile().getAbsolutePath());
  +log("Building MANIFEST-only jar: " 
  ++ getDestFile().getAbsolutePath());
   zOut = new ZipOutputStream(new FileOutputStream(getDestFile()));
   
   zOut.setEncoding(getEncoding());
  
  
  
  1.101 +64 -11ant/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.100
  retrieving revision 1.101
  diff -u -r1.100 -r1.101
  --- Zip.java  7 Mar 2003 11:23:03 -   1.100
  +++ Zip.java  12 Mar 2003 11:23:27 -  1.101
  @@ -344,7 +344,11 @@
   // we don't need to update if the original file doesn't exist
   
   addingNewFiles = true;
  -doUpdate = doUpdate && zipFile.exists();
  +if (doUpdate && !zipFile.exists()) {
  +doUpdate = false;
  +log("ignoring update attribute as " + archiveType
  ++ " doesn't exist.", Project.MSG_DEBUG);
  +}
   
   // Add the files found in groupfileset to fileset
   for (int i = 0; i < groupfilesets.size(); i++) {
  @@ -381,14 +385,16 @@
   vfss.copyInto(fss);
   boolean success = false;
   try {
  -Resource[][] addThem = getResourcesToAdd(fss, zipFile, false);
  +// can also handle empty archives
  +ArchiveState state = getResourcesToAdd(fss, zipFile, false);
   
   // quick exit if the target is up to date
  -// can also handle empty archives
  -if (isEmpty(addThem)) {
  +if (!state.isOutOfDate()) {
   return;
   }
   
  +Resource[][] addThem = state.getResourcesToAdd();
  +
   if (doUpdate) {
   renamedFile =
   fileUtils.createTempFile("zip", ".tmp",
  @@ -687,17 +693,38 @@
* out-of-date.  Subclasses overriding this method are supposed to
* set this value correctly in their call to
* super.getResourcesToAdd.
  - * @return an array of resources to add for each fileset passed in.
  + * @return an array of resources to add for each fileset passed in as 
well
  + * as a flag that indicates whether the archive is uptodate.
*
* @exception BuildException if it likes
*/
  -protected Resource[][] getResourcesToAdd(FileSet[] filesets,
  +protected ArchiveState getResourcesToAdd(FileSet[] filesets,
File zipFile,
boolean needsUpdate)
   throws BuildException {
   
   Resource[][] initialResources = grabResources(filesets);
   if (isEmpty(initialResources)) {
  +if (needsUpdate && doUpdate) {
  +/*
  + * This is a rather hairy case.
  + *
  + * One of our subclasses knows that we need to update the
  + * archive, but at the same time, there are no resources
  + * known to us that would need to be added.  Only the
  + * subclass seems to know what's going on.
  + *
  + * This happens if  detects that the manifest has 
changed,
  + * for example.  The manifest is not

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

[bodewig]

bodewig 2003/03/12 03:29:10

  Modified:src/etc/testcases/taskdefs Tag: ANT_15_BRANCH jar.xml
   src/main/org/apache/tools/ant/taskdefs Tag: ANT_15_BRANCH
Jar.java Zip.java
   src/testcases/org/apache/tools/ant/taskdefs Tag:
ANT_15_BRANCH JarTest.java
  Log:
  Merge tests and fix for bug 17780 from HEAD
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.4.2.4   +11 -0 ant/src/etc/testcases/taskdefs/jar.xml
  
  Index: jar.xml
  ===
  RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/jar.xml,v
  retrieving revision 1.4.2.3
  retrieving revision 1.4.2.4
  diff -u -r1.4.2.3 -r1.4.2.4
  --- jar.xml   26 Feb 2003 10:07:00 -  1.4.2.3
  +++ jar.xml   12 Mar 2003 11:29:09 -  1.4.2.4
  @@ -189,4 +189,15 @@
   
 
   
  +  
  +  
  +
  +  
  +
  +  
  +
  +
  +
  +  
   
  
  
  
  No   revision
  
  
  No   revision
  
  
  1.51.2.17 +5 -3  ant/src/main/org/apache/tools/ant/taskdefs/Jar.java
  
  Index: Jar.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Jar.java,v
  retrieving revision 1.51.2.16
  retrieving revision 1.51.2.17
  diff -u -r1.51.2.16 -r1.51.2.17
  --- Jar.java  19 Feb 2003 08:13:59 -  1.51.2.16
  +++ Jar.java  12 Mar 2003 11:29:10 -  1.51.2.17
  @@ -535,11 +535,12 @@
* out-of-date.  Subclasses overriding this method are supposed to
* set this value correctly in their call to
* super.getResourcesToAdd.
  - * @return an array of resources to add for each fileset passed in.
  + * @return an array of resources to add for each fileset passed in as 
well
  + * as a flag that indicates whether the archive is uptodate.
*
* @exception BuildException if it likes
*/
  -protected Resource[][] getResourcesToAdd(FileSet[] filesets,
  +protected ArchiveState getResourcesToAdd(FileSet[] filesets,
File zipFile,
boolean needsUpdate)
   throws BuildException {
  @@ -585,7 +586,8 @@
   
   ZipOutputStream zOut = null;
   try {
  -log("Building jar: " + getDestFile().getAbsolutePath());
  +log("Building MANIFEST-only jar: " 
  ++ getDestFile().getAbsolutePath());
   zOut = new ZipOutputStream(new FileOutputStream(getDestFile()));
   
   zOut.setEncoding(getEncoding());
  
  
  
  1.78.2.13 +64 -11ant/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.78.2.12
  retrieving revision 1.78.2.13
  diff -u -r1.78.2.12 -r1.78.2.13
  --- Zip.java  7 Mar 2003 12:38:39 -   1.78.2.12
  +++ Zip.java  12 Mar 2003 11:29:10 -  1.78.2.13
  @@ -327,7 +327,11 @@
   // we don't need to update if the original file doesn't exist
   
   addingNewFiles = true;
  -doUpdate = doUpdate && zipFile.exists();
  +if (doUpdate && !zipFile.exists()) {
  +doUpdate = false;
  +log("ignoring update attribute as " + archiveType
  ++ " doesn't exist.", Project.MSG_DEBUG);
  +}
   
   // Add the files found in groupfileset to fileset
   for (int i = 0; i < groupfilesets.size(); i++) {
  @@ -364,14 +368,16 @@
   vfss.copyInto(fss);
   boolean success = false;
   try {
  -Resource[][] addThem = getResourcesToAdd(fss, zipFile, false);
  +// can also handle empty archives
  +ArchiveState state = getResourcesToAdd(fss, zipFile, false);
   
   // quick exit if the target is up to date
  -// can also handle empty archives
  -if (isEmpty(addThem)) {
  +if (!state.isOutOfDate()) {
   return;
   }
   
  +Resource[][] addThem = state.getResourcesToAdd();
  +
   if (doUpdate) {
   renamedFile =
   fileUtils.createTempFile("zip", ".tmp",
  @@ -666,17 +672,38 @@
* out-of-date.  Subclasses overriding this method are supposed to
* set this value correctly in their call to
* super.getResourcesToAdd.
  - * @return an array of resources to add for each fileset passed in.
  + * @return an array of resources to add for each fileset passed in as 
well
  + * as a flag that indicates whether the archive is uptodate.
*
* @exception BuildException if it likes
*/
 

DO NOT REPLY [Bug 17780] - Instead of updating a jar file, the task overrides it.

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

Instead of updating a jar file, the task overrides it.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 11:31 ---
Ben, I'm quite sure that your case is a duplicate of bug 17648.

Anyway, both bugs are supposed to be fixed now.  Could you please replace 
ant.jar
from Ant 1.5.2 with this one  and
verify that it fixes all problems you have encountered?

cvs commit: ant WHATSNEW

[bodewig]

bodewig 2003/03/12 03:41:06

  Modified:.Tag: ANT_15_BRANCH WHATSNEW
  Log:
  keep track of changes
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.263.2.125 +25 -0 ant/WHATSNEW
  
  Index: WHATSNEW
  ===
  RCS file: /home/cvs/ant/WHATSNEW,v
  retrieving revision 1.263.2.124
  retrieving revision 1.263.2.125
  diff -u -r1.263.2.124 -r1.263.2.125
  --- WHATSNEW  28 Feb 2003 15:19:58 -  1.263.2.124
  +++ WHATSNEW  12 Mar 2003 11:41:05 -  1.263.2.125
  @@ -1,3 +1,28 @@
  +Changes from Ant 1.5.2 to Ant 1.5.3
  +===
  +
  +Changes that could break older environments:
  +
  +
  +* The  task and friends have again changed a method signature
  +  (sorry, was necessary to fix bug 17780).  The return type of
  +  getResourcesToAdd has changed.
  +
  +Fixed bugs:
  +---
  +
  +* 's filemode would get ignored and the dirmode was used
  +  for the included files as well.  As a side effect, WinZIP was unable
  +  to extract or display the files, so they seemed to be missing from
  +  the archive.  Bugzilla Report 17648.
  +
  +*  could use the wrong path separator when trying to change the
  +  remote working directory.  Bugzilla Report 17735.
  +
  +*  would loose all original files if you didn't
  +  specify any nested <(zip)fileset>s and the manifest had changed.
  +  Bugzilla Report 17780.
  +
   Changes from Ant 1.5.1 to Ant 1.5.2
   ===
   
  
  
  

cvs commit: ant WHATSNEW

[bodewig]

bodewig 2003/03/12 03:41:36

  Modified:.WHATSNEW
  Log:
  keep track of changes
  
  Revision  ChangesPath
  1.362 +25 -0 ant/WHATSNEW
  
  Index: WHATSNEW
  ===
  RCS file: /home/cvs/ant/WHATSNEW,v
  retrieving revision 1.361
  retrieving revision 1.362
  diff -u -r1.361 -r1.362
  --- WHATSNEW  6 Mar 2003 12:42:43 -   1.361
  +++ WHATSNEW  12 Mar 2003 11:41:36 -  1.362
  @@ -161,6 +161,31 @@
 jsch, a BSD licensed SSH library that can be found at 
 http://www.jcraft.com/jsch/index.html
   
  +Changes from Ant 1.5.2 to Ant 1.5.3
  +===
  +
  +Changes that could break older environments:
  +
  +
  +* The  task and friends have again changed a method signature
  +  (sorry, was necessary to fix bug 17780).  The return type of
  +  getResourcesToAdd has changed.
  +
  +Fixed bugs:
  +---
  +
  +* 's filemode would get ignored and the dirmode was used
  +  for the included files as well.  As a side effect, WinZIP was unable
  +  to extract or display the files, so they seemed to be missing from
  +  the archive.  Bugzilla Report 17648.
  +
  +*  could use the wrong path separator when trying to change the
  +  remote working directory.  Bugzilla Report 17735.
  +
  +*  would loose all original files if you didn't
  +  specify any nested <(zip)fileset>s and the manifest had changed.
  +  Bugzilla Report 17780.
  +
   Changes from Ant 1.5.1 to Ant 1.5.2
   =
   
  
  
  

DO NOT REPLY [Bug 17780] - Instead of updating a jar file, the task overrides it.

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

Instead of updating a jar file, the task overrides it.





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 14:11 ---
Stefan,

The new ant.jar you provided fixes all my problems.

Thank you for your quick response!

DO NOT REPLY [Bug 17883] - Custom task containers don't share property state across subtasks

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

Custom task containers don't share property state across subtasks





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 14:58 ---
So this was an intentional change in how things worked in TaskContainers 
between 1.4.1 and 1.5.2?  I didn't think you would want to break existing 
scripts.  I would think the default for custom tasks that implement 
TaskContainer would be that all subtasks are executed sequentially.  Note that 
my custom task isn't just a plain vanilla container; it does some other things -
 I just reduced it down to the simplest form to illustrate the problem

DO NOT REPLY [Bug 17883] - Custom task containers don't share property state across subtasks

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

Custom task containers don't share property state across subtasks





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 15:52 ---
Some internal APIs changed to adapt for a bug that couldn't get fixed otherwise
IIRC.

We try to keep a reasonable level of backwards compatibility, but from time to
time we are forced to changed APIs if it was impossible or unreasonably
cumbersome to fix problems otherwise.

The changes in question are

in response to bug 9259 which in turn became necessary because of some other
changes - I think because of

which was necessary to allow users to define tasks that have the same name as
built-in tasks.

DO NOT REPLY [Bug 14553] - Add support for a separate CLASSPATH

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

Add support for a separate CLASSPATH





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 15:56 ---
I need this functionallity to be able to have Ant find optional and homebuild 
tasks. And the libraries needed for this I do not see the need for putting it 
in 
each and every ant installation on developers machines (e.g. ant/lib).


And we actually have 3-4 versions of ant installed as different projects are 
using different Ant's...




Furthermore I do not like that the classpath contains .jars that ONLY ant 
needs, 
not my application etc. It should be as clean as possible!




Thus if the wrapper script "listened" to e.g. ANTCLASSPATH as mentioned in my 
first message, then I could clear the CLASSPATH all together and only add ant 
related .jars to the ANTCLASSPATH - thus ensuring that my app is not 
"influenced" by any .jars needed by ant.

Regression in CVS HEAD - probably related to embed proposal

[Stefan Bodewig]

Hi,

while investigating the history of Bug 17883 (I thought that the stuff
hadn't worked in 1.4.1 either, I was wrong) I realized that this build
file


  

  
  ${foo}

  


will print

seq:
 [echo] ${foo}

BUILD SUCCESSFUL

with CVS HEAD.

You get bar instead of ${foo} with Ant 1.4 up to 1.5.2 (or HEAD of the
1.5 branch for that matter).

I could commit a testcase to proof this, but wanted to state the
problem here before we get the same Gump test failure mail for weeks.

Stefan

DO NOT REPLY [Bug 17923] New: - Update Jar results in Jar 'unreadable' by Winzip

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

Update Jar results in Jar 'unreadable' by Winzip

   Summary: Update Jar results in Jar 'unreadable' by Winzip
   Product: Ant
   Version: 1.5.2
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Since i've stepped over from 1.5.1 to 1.5.2. 


I have problems doing the  task with update=true.


A jar that has been created with this option can be opened in WinZip but only 
the last added files are visible. 


BUT when i do a unzip -l MYjar.jar  I do see All files.


Apparantely the jar is created with a format not conform Winzip's expected 
format

DO NOT REPLY [Bug 17871] - war task's webxml attrib no longer is able to use value with a starting backslash for the path in Windows

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

war task's webxml attrib no longer is able to use value with a starting 
backslash for the path in Windows





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 16:26 ---
Are you sure it gets ignored?  How do you check the resulting war archive?

WinZIP?  Does your web.xml show up if you run "jar tf" against the war file?

If you answer yes to the last two questions, please mark this bug as a duplicate
of bug 17648.

DO NOT REPLY [Bug 17883] - Custom task containers don't share property state across subtasks

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

Custom task containers don't share property state across subtasks

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 16:28 ---
Ok, I was able to work around the problem through the use of heavy reflection, 
following the pattern of the Sequential task.  Now my custom task works in both 
Ant 1.4.1 and Ant 1.5.2.

DO NOT REPLY [Bug 17923] - Update Jar results in Jar 'unreadable' by Winzip

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

Update Jar results in Jar 'unreadable' by Winzip

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE
   Target Milestone|--- |1.5.3



--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 16:33 ---


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

DO NOT REPLY [Bug 17648] - not working for zip 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=17648

 not working for zip task

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 16:33 ---
*** Bug 17923 has been marked as a duplicate of this bug. ***

DO NOT REPLY [Bug 17883] - Custom task containers don't share property state across subtasks

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

Custom task containers don't share property state across subtasks





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 16:34 ---
I wouldn't call the report invalid 8-)

Do you want to (canb your) share the heavy reflection part so that other task
writers in a similar situation could benefit from it?

DO NOT REPLY [Bug 17883] - Custom task containers don't share property state across subtasks

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

Custom task containers don't share property state across subtasks





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 16:36 ---
s/canb your/can you/ - sorry.  Do you know the feeling when you detect a really
ugly typo right at the moment after pressing the submit button?

DO NOT REPLY [Bug 17782] - expandproperties not substituting within same file

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

expandproperties not substituting within same file





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 16:43 ---
Is this issue similar to the one that caused  and other 
TaskContainer implementors to have to override maybeConfigure(), as described 
in bug 17883 ?

DO NOT REPLY [Bug 17871] - war task's webxml attrib no longer is able to use value with a starting backslash for the path in Windows

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

war task's webxml attrib no longer is able to use value with a starting 
backslash for the path in Windows





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 16:45 ---
I verified that it gets ignored.  I used both UnZip 5.41 and jar (JDK1.4.1_02) 
[both on Windows].

(Besides, when the "war" task runs, it just so happens that there is a "WEB-
INF/web.xml" file in the selected war files of the task, so the task 
displays "[war] Warning: selected war files include a WEB-INF/web.xml which 
will be ignored (please use webxml attribute to war task)" when the "webxml" 
attrib of the task has something like "\Xxx\Yyy\Zzz.xml" -- presumably because 
the task was not able to find "\Xxx\Yyy\Zzz.xml" to use as the "web.xml" file; 
but when the "webxml" attrib is "D:\Xxx\Yyy\Zzz.xml", then all is well.  Keep 
in mind that Ant is invoked on the Windows command line at the "D:" drive, the 
build file is also located on the "D:" drive, and all the files that the task 
uses are also on the "D:" drive.)

So I believe that this issue is NOT a duplicate of bug 17648.

RE: ssh exec task...

[Anderson, Rob H - VSCM]

Attached is the documentation (I hope).

-Rob A

-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2003 12:35 AM
To: [EMAIL PROTECTED]
Subject: Re: ssh exec task...


On Tue, 11 Mar 2003, Rob H. Anderson <[EMAIL PROTECTED]>
wrote:

> Attached is the documentation.

No it isn't (no HTML parts on our list, even attachments).  Could you
either send it to me directly or simply zip it up before attaching it?

> I wonder if there is anyway to wait for the thread to finnish?

So do I.  I played with reading from the outputstream (much like the
StreamPumper stuff in ) in the hope the IO would block, but have
no good results so far.

I'll try to understand the inner workings of jsch (though my time is a
bit limited ATM) and ask on jsch-users if all else fails.  You are
invited to do some research of your own, of course 8-)

> Does this mean that ant will report "Build Successfull" before the
> command has actually completed (Yuk)?

Potentially.

Stefan

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

DO NOT REPLY [Bug 17883] - Custom task containers don't share property state across subtasks

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

Custom task containers don't share property state across subtasks





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 16:52 ---
It seems to be like TaskContainer should have some overridable setting to make
this behaviour work.  You don't really want some bag of code that everyone has
to add to their own tasks to make it work the way you would expect to.

Or a new subclass of TaskContainer (not sure if this is feasible; been a while
since I looked at this), that does the property thing right ...

DO NOT REPLY [Bug 17782] - expandproperties not substituting within same file

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

expandproperties not substituting within same file





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 16:58 ---
No, unrelated.

This bug here has a rather simple reason.  The expandproperties filter gets to
read the file line by line and ask the project instance for defined properties.
loadproperties in turn will read the entire file, before setting any properties
in the project.  This means, the project won't know about the properties in the
file before it has been read completely.

This is rather tedious to fix as the filter must not keep track of the 
properties
it has already read as a filter coming later in the chain may cancel out the
line defining the property.

Making loadproperties read the file line by line may not solve the problem 
either
as we may have filters in the chain that have to read multiple lines at once
to do their job.  If they read four lines further just to realize they can
pass up a certain line, property expansion wouldn't work for these four lines
and an expandproperties filter that gets invoked first (hope I haven't lost 
you).

I don't see a solution ATM (otherwise the bug would have been assigned to
myself).  If loading a property file and expanding properties that have been
defined in the file on the fly is all you need,  currently
looks like the better alternative.

DO NOT REPLY [Bug 17883] - Custom task containers don't share property state across subtasks

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

Custom task containers don't share property state across subtasks





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 16:58 ---
I agree with Pat... a new subclass to handle this for users would be nice.

Here's my contribution to how I worked around the problem.  I think you could 
create a subclass of TaskContainer to hold this stuff that Sequential could 
override.

BTW... I wonder why Bugzilla hasn't yet made it possible to edit existing 
comments - would allow folks to clean up typos or sensitive information that 
should never have been posted.

--- code below ---

//
/**
 * Use reflection to find any public or protected method in
 * the hierarchy of starterClass.
 */
public static Method findMethod(Class starterClass, String methodName, Class[] 
definedArgTypes) {
Class currentClass = starterClass;
while ((currentClass != null)) {
try {
return currentClass.getDeclaredMethod(methodName, 
definedArgTypes);
} catch (NoSuchMethodException e) {
currentClass = currentClass.getSuperclass();
}
}
return null;
}

//
/**
 * Convenience method for the other findMethod() so that callers don't need
 * to send getClass().
 */
public static Method findMethod(Object receiver, String methodName, Class[] 
definedArgTypes) {
return findMethod(receiver.getClass(), methodName, definedArgTypes);
}

//
/**
 * Workaround for design change in Ant 1.5.2 with preserving property state
 * between contained tasks.  In Ant 1.4.1, it won't find the isInvalid()
 * method, and will end up just calling the parent class maybeConfigure(),
 * so this approach is backward compatible.
 */
public void maybeConfigure() throws BuildException {
Method isInvalidMethod = findMethod(this, "isInvalid", null);
if (isInvalidMethod == null) {
super.maybeConfigure();
return;
}
Object isInvalidResult = null;
try {
isInvalidResult = isInvalidMethod.invoke(this, new Object[] {});
} catch (IllegalAccessException e) {
} catch (InvocationTargetException e) {
}
if (((Boolean) isInvalidResult).booleanValue()) {
super.maybeConfigure();
} else {
Method maybeConfigureTwoArgMethod = null;
maybeConfigureTwoArgMethod =
findMethod(getRuntimeConfigurableWrapper(),
"maybeConfigure",
new Class[] { Project.class, boolean.class });
if (maybeConfigureTwoArgMethod == null) {
// should not occur, since we already found isInvalid(),
// which was made available in the same Ant version as
// the 2-arg maybeConfigure()
System.out.println("couldn't find method 
maybeConfigure");
return;
}
try {
maybeConfigureTwoArgMethod.invoke
(getRuntimeConfigurableWrapper(), new Object[] {getProject(), Boolean.FALSE});
} catch (IllegalAccessException e) {
} catch (InvocationTargetException e) {
}
}
}

DO NOT REPLY [Bug 17871] - war task's webxml attrib no longer is able to use value with a starting backslash for the path in Windows

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

war task's webxml attrib no longer is able to use value with a starting 
backslash for the path in Windows





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 17:04 ---
Hmm,

the main change is that the webxml attribute now uses 's file
attribute internally.  I don't have Windows around, could you please try this
snippet and port the result?


  


${foo-as-prop}

and compare it to


  


${foo-as-prop}

they are supposed to echo the same file name.

Re: ssh exec task...

[Stefan Bodewig]

On Wed, 12 Mar 2003, Rob H. Anderson <[EMAIL PROTECTED]>
wrote:

> Attached is the documentation (I hope).

I received nothing.

Stefan

DO NOT REPLY [Bug 14553] - Add support for a separate CLASSPATH

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

Add support for a separate CLASSPATH





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 17:15 ---
You do not need this functionality for home built tasks; you just include a
classpath in the  declarations. You may need it for optional tasks, but
you really ought to have the versions of things (like junit) that ant was built
against, as differences cause trouble.

You may want to know that the startup scripts cause an inordinate amount of
support calls, especially related to win9x, cygwin, 4nt, and obscure unix
variants, spaces in file and directory names and other little gotchas. For this
reason we are very leery of changing them when they seem to work, and are mostly
on 'touch only when support calls come in as pre-release testing is impossible'.
For this reason, even simple changes are viewed as dangerous. You are of course,
free to change your copies. I have been known to have different versions of
runant.pl for different projects for related purposes.

In ant1.6 we are actually looking at replacing the .bat based classloading
process with a boot loader jar, similar to that of tomcat, though performance is
 potentially an issue there. supporting a new env variable in that process may
work. 

Leaving the report as open till that time.

cvs commit: ant KEYS

[umagesh]

umagesh 2003/03/12 09:14:35

  Modified:.KEYS
  Log:
  Update sig
  
  Revision  ChangesPath
  1.10  +33 -0 ant/KEYS
  
  Index: KEYS
  ===
  RCS file: /home/cvs/ant/KEYS,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- KEYS  7 Mar 2003 11:56:10 -   1.9
  +++ KEYS  12 Mar 2003 17:14:35 -  1.10
  @@ -223,3 +223,36 @@
   P9A=
   =hQhz
   -END PGP PUBLIC KEY BLOCK-
  +pub  1024D/EDF62C35 2002-04-10 Magesh Umasankar <[EMAIL PROTECTED]>
  +sigEDF62C35 2002-04-10  Magesh Umasankar <[EMAIL PROTECTED]>
  +sig5F6B8B72 2003-03-07  Stefan Bodewig <[EMAIL PROTECTED]>
  +sub  1024g/B5FFC53F 2002-04-10
  +sigEDF62C35 2002-04-10  Magesh Umasankar <[EMAIL PROTECTED]>
  +
  +-BEGIN PGP PUBLIC KEY BLOCK-
  +Version: GnuPG v1.0.6-2 (MingW32)
  +Comment: For info see http://www.gnupg.org
  +
  +mQGiBDy0ebgRBADuKIKD8PuJ4wKEV1h2AprwJjxCRx8vn48XNwfLZuvhw8cpArtK
  +rZwhoGPPUPEEXgtTNerlKq4VwpAwcnvRz7oC/7aWkUbcR2sAyhfe2scohwPgw7Xv
  ++isWC0NDPdrxvXG/PUOG/cnELunr51ymybBqBxUd2gMhYIxPo67D+YPYLwCgwcZp
  +yc/6kJa116ESWHrti342GD8D/1srpnRs9CiS1DQF1uZ1wW4vzj4VD61tKsjdWD8D
  +V573R22iMDLSj4oMB536WxUH7snz8XsAKm/peqJ6G9m0smtmWA1ago5yzQj70WqF
  +xzWBhHn2I/YfAQ8pb2s9q1lClj8elnCxT65L27ydBAZteejb2VqjtQ6iGy86PUT2
  +wRUvBADZmoV1eIZJEM5NnxBv1EtvRYZtIQEzZ8dO2A1LOS7qlVr8IypljNPLGhzX
  +VHNvVsjC9QMUSWeBsDedvQHQ3hJpIMnTI32XE1V4gX06gfVTZdhf2fLTtwnsHZp0
  +oumqshGDVRhNJJdDYLikxWOxOfkNveKEqJFvtuBR+ZqqluQKebQlTWFnZXNoIFVt
  +YXNhbmthciA8dW1hZ2VzaEBhcGFjaGUub3JnPohXBBMRAgAXBQI8tHm4BQsHCgME
  +AxUDAgMWAgECF4AACgkQ76Pnee32LDWSRwCfeASWXvpdt7bSFPMtszU/7uPEktsA
  +n23mYUN5WKJA1ZreW+0CcZ2ESnOviEYEExECAAYFAj5ogYgACgkQohFa4V9ri3IW
  +YACgsxGig0PL0M86rJsA/IpXjBdg3ysAoJzsoUZ/7s2BxDfzF/FRTVIzS+TMuQEN
  +BDy0eb8QBACBVb9YDJRp9Irzmq71Jf9FIPw+4g/cWpF3t/Eb7eSzMcOvTAXyNIWz
  +aaOjHre7lFctHfq8ls/6gR7uqajiAnfQcfTcu7pp+F5KsU0Embt83SFzZ3aoJwET
  +mB/LqUyrrGDiue3lU+flJO7UmcsRvtk0+BDkyCeB9HgfdpXbBLCyuwADBQP+PNxX
  +4e1tg3ZJo/xNEnD2Re3HjmQRrr0RYJLUGjgQrAEONSgowx3IW8/JssmNJVjnYm0q
  +jSKsb8rergCFJhPNZ8Dd/k00pKcrq+IN6j7WTYLqPce87zrGAZUtmDwDSp5mxy5E
  +xWJJxsgBPk4YBQLzJt21A3BgK/i24Sze2VLbaZuIRgQYEQIABgUCPLR5vwAKCRDv
  +o+d57fYsNa8xAJ4mLfonZbd64+YY9rfvhIh3Vsl3AACeLPPKtma2K6XCfhTBEDnj
  +hzSr4vo=
  +=lBfF
  +-END PGP PUBLIC KEY BLOCK-
  
  
  

cvs commit: ant KEYS

[umagesh]

umagesh 2003/03/12 09:15:03

  Modified:.Tag: ANT_15_BRANCH KEYS
  Log:
  Update sig
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.6.2.4   +34 -0 ant/KEYS
  
  Index: KEYS
  ===
  RCS file: /home/cvs/ant/KEYS,v
  retrieving revision 1.6.2.3
  retrieving revision 1.6.2.4
  diff -u -r1.6.2.3 -r1.6.2.4
  --- KEYS  7 Mar 2003 12:36:18 -   1.6.2.3
  +++ KEYS  12 Mar 2003 17:15:03 -  1.6.2.4
  @@ -223,3 +223,37 @@
   P9A=
   =hQhz
   -END PGP PUBLIC KEY BLOCK-
  +
  +pub  1024D/EDF62C35 2002-04-10 Magesh Umasankar <[EMAIL PROTECTED]>
  +sigEDF62C35 2002-04-10  Magesh Umasankar <[EMAIL PROTECTED]>
  +sig5F6B8B72 2003-03-07  Stefan Bodewig <[EMAIL PROTECTED]>
  +sub  1024g/B5FFC53F 2002-04-10
  +sigEDF62C35 2002-04-10  Magesh Umasankar <[EMAIL PROTECTED]>
  +
  +-BEGIN PGP PUBLIC KEY BLOCK-
  +Version: GnuPG v1.0.6-2 (MingW32)
  +Comment: For info see http://www.gnupg.org
  +
  +mQGiBDy0ebgRBADuKIKD8PuJ4wKEV1h2AprwJjxCRx8vn48XNwfLZuvhw8cpArtK
  +rZwhoGPPUPEEXgtTNerlKq4VwpAwcnvRz7oC/7aWkUbcR2sAyhfe2scohwPgw7Xv
  ++isWC0NDPdrxvXG/PUOG/cnELunr51ymybBqBxUd2gMhYIxPo67D+YPYLwCgwcZp
  +yc/6kJa116ESWHrti342GD8D/1srpnRs9CiS1DQF1uZ1wW4vzj4VD61tKsjdWD8D
  +V573R22iMDLSj4oMB536WxUH7snz8XsAKm/peqJ6G9m0smtmWA1ago5yzQj70WqF
  +xzWBhHn2I/YfAQ8pb2s9q1lClj8elnCxT65L27ydBAZteejb2VqjtQ6iGy86PUT2
  +wRUvBADZmoV1eIZJEM5NnxBv1EtvRYZtIQEzZ8dO2A1LOS7qlVr8IypljNPLGhzX
  +VHNvVsjC9QMUSWeBsDedvQHQ3hJpIMnTI32XE1V4gX06gfVTZdhf2fLTtwnsHZp0
  +oumqshGDVRhNJJdDYLikxWOxOfkNveKEqJFvtuBR+ZqqluQKebQlTWFnZXNoIFVt
  +YXNhbmthciA8dW1hZ2VzaEBhcGFjaGUub3JnPohXBBMRAgAXBQI8tHm4BQsHCgME
  +AxUDAgMWAgECF4AACgkQ76Pnee32LDWSRwCfeASWXvpdt7bSFPMtszU/7uPEktsA
  +n23mYUN5WKJA1ZreW+0CcZ2ESnOviEYEExECAAYFAj5ogYgACgkQohFa4V9ri3IW
  +YACgsxGig0PL0M86rJsA/IpXjBdg3ysAoJzsoUZ/7s2BxDfzF/FRTVIzS+TMuQEN
  +BDy0eb8QBACBVb9YDJRp9Irzmq71Jf9FIPw+4g/cWpF3t/Eb7eSzMcOvTAXyNIWz
  +aaOjHre7lFctHfq8ls/6gR7uqajiAnfQcfTcu7pp+F5KsU0Embt83SFzZ3aoJwET
  +mB/LqUyrrGDiue3lU+flJO7UmcsRvtk0+BDkyCeB9HgfdpXbBLCyuwADBQP+PNxX
  +4e1tg3ZJo/xNEnD2Re3HjmQRrr0RYJLUGjgQrAEONSgowx3IW8/JssmNJVjnYm0q
  +jSKsb8rergCFJhPNZ8Dd/k00pKcrq+IN6j7WTYLqPce87zrGAZUtmDwDSp5mxy5E
  +xWJJxsgBPk4YBQLzJt21A3BgK/i24Sze2VLbaZuIRgQYEQIABgUCPLR5vwAKCRDv
  +o+d57fYsNa8xAJ4mLfonZbd64+YY9rfvhIh3Vsl3AACeLPPKtma2K6XCfhTBEDnj
  +hzSr4vo=
  +=lBfF
  +-END PGP PUBLIC KEY BLOCK-
  
  
  

RE: ssh exec task...

[Anderson, Rob H - VSCM]

Crap! I have sent the attachements to your email address
([EMAIL PROTECTED]).

-Rob A

-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2003 9:05 AM
To: [EMAIL PROTECTED]
Subject: Re: ssh exec task...


On Wed, 12 Mar 2003, Rob H. Anderson <[EMAIL PROTECTED]>
wrote:

> Attached is the documentation (I hope).

I received nothing.

Stefan

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

DO NOT REPLY [Bug 17871] - war task's webxml attrib no longer is able to use value with a starting backslash for the path in Windows

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

war task's webxml attrib no longer is able to use value with a starting 
backslash for the path in Windows





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 17:37 ---
For the following "test" task:



  




  

  

  


${foo-as-prop}
  

  

  


${foo-as-prop}
  

  


  

  


  




Here is the output:



Buildfile: D:\Stoehr\cincro\src\build.xml

test:

test1:
 [echo] D:\Xxx\Yyy\Zzz.xml

test2:
 [echo] D:\Xxx\Yyy\Zzz.xml

test3:
  [war] Building war: D:\test3.war
  [war] Warning: selected war files include a WEB-INF/web.xml which will be 
ignored (please use webxml attribute to war task)

test4:
  [war] Building war: D:\test4.war

BUILD SUCCESSFUL
Total time: 1 second

DO NOT REPLY [Bug 17871] - war task's webxml attrib no longer is able to use value with a starting backslash for the path in Windows

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

war task's webxml attrib no longer is able to use value with a starting 
backslash for the path in Windows





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 17:48 ---
One clarification about the "test3" and "test4" tasks are that there are no 
files to be included in the war file except for the "web.xml" file.  So it is 
weird to get the "war" warning for the "test3" task.

Also note that in both cases, the "destfile" attrib of the "war" task does not 
include the drive -- yet the "war" task was able to output both war files at 
the correct location.

RE: enhanced pvcs task for PVCS version 7.5

[Anderson, Rob H - VSCM]

Apparently there is some confusion around repository and config file. I
apologize for not being very clear about this. Let me explain. By default,
when you create a Version Manager project database a config file is created
in the archives directory. You can see the config file name and location
through the GUI if you right click the project database and choose
"Properties". You can, however, specify a config file to use when you create
the project database (in the advanced tab) or at any time through the
"Properties" dialog. For example: I have a local repository that I created
using the defualts ("Create a new config file" in the Advanced tab) for a
config file. The layout is as follows;

Project Database (-pr)
c:\pvcs
Config file
c:\pvcs\archives\cos0nbu1.cfg

I have a shared project database that was created with a custom config file
("Use an existing configuration file" in the Advanced tab)

Project Database (-pr)
s:\Projects\NOONAN
Config File
s:\configuration files\NOONAN.cfg

In both cases, using get works fine without the -c option unless I am doing
a get by promotion group. When doing a get by promotion group I will get an
error that says "get: Group "CM" does not exist in promotion hierarchy.",
because the promotion model is defined in the config file. So, if I specify
the config file with the -c option, this error goes away and the get by
promotion group works as expected.

So using the pvcs task is no different. Doing a normal "get" works fine, but
a "get by promotion group" fails with the error mentioned above. If there
was a configfile attribute to the pvcs task I could use it to get by
promotion group. Currently I can only use it to do a "get the default
revision". Does this make sense?

-Rob A

 
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 3:22 PM
To: Ant Developers List
Subject: RE: enhanced pvcs task for PVCS version 7.5




PVCS task works with version 7.5 as is, unless you are pointing to a config
file other than the default.


"repository" attribute is used to point to config location, do you mean
some other configuration files; and as you know this a required attribute,
so no defaults.


The advantage to using "pcli get" rather than
"get" is that pcli is smart about config files, which has been a problem
for
me with the existing PVCS task.I'm a little new to PVCS Version Manager, so
if there are other advantages please let me know. Of course pcli is pretty
slow compared to the old school "get".


Following are advantages stated by our support team:-


All project teams that have been using the legacy Commands (i.e. get, put)
will need to convert to 'PCLI'. Using the PCLI commands is just like using
the I-NET client or Windows client. These three interfaces update
serialized database files that the PVCS Version Manager software uses.
These serialized database files contain all the information for the
archives.  So if one member is using PVCS I-NET and modifies an item that
modification will appear for another team member that is using the PCLI
commands.  Using the old sget or sput does not update these serialized
files.

1.) Easier/More User Friendly
2.) More Reliable
3.) Provides your team the choice to use Command Line or I-NET Client.
4.)May run a little slower since it is updating the serialized files.



It would be nice if the existing PVCS task had a "configfile" parameter.


Can you explain a bit more about this? because I don't seem to have any
problem when using with old get, with respect to the config files.

Please find the attachment. Don't miss the added (two) properties.



..(See attached file: Pvcs.java)
Chandra Periyaswamy



 

  "Anderson, Rob  H

  - VSCM"  To:   "'Ant Developers
List'" <[EMAIL PROTECTED]>  
  <[EMAIL PROTECTED]cc:

  torscm.com>  Subject:  RE: enhanced pvcs
task for PVCS version 7.5   
 

  03/11/2003 05:00

  PM

  Please respond to

  "Ant Developers

  List"

 

 





PVCS task works with version 7.5 as is, unless you are pointing to a config
file other than the default. The advatantage to using "pcli get" rather
than
"get" is that pcli is smart about config files, which has been a problem
for
me with the existing PVCS task. I'm a little new to PVCS Version Manager,
so
if there are other advantages please let me know. Of course pcli is pretty
slow compared to the old school "get". It would be nice if the existing
PVCS
task had a "configfile" parameter. I would like to check out your source
code. Please attach it to an email and send it to the list. Thanks,

-Rob A



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 12:14 PM
To: [EMAIL PROTECTED]

DO NOT REPLY [Bug 17883] - Custom task containers don't share property state across subtasks

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

Custom task containers don't share property state across subtasks





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 18:15 ---
Um ... icky?

Is reflection the only answer here?  It seems like it would be safer, if
possible, to check some kind of Ant version constant, and call stuff differently
based on it.  This would only work, of course, if the 'newer' Ant didn't
actually remove any methods from the 'older' Ant.  Which from code, I'm guessing
it didn't (the newer Ant has some kind of new isInvalid() method on something,
and also has a two-arg maybeConfigure(), but the old Ant and new Ant both have
no-arg maybeConfigure().  Making the code more like:

public void maybeConfigure() throws BuildException {
if (Ant.Version < 1.5) {
super.maybeConfigure()
}
else {
super.maybeConfigure(getProject().false);
}
}

A little shorter.  And clearer. 

Assumption is you can compile this against Ant 1.5, but it will actually run
fine on Ant 1.4, since it never tries to execute the 2-arg maybeConfigure() 
call.

Not being able to edit existing comments is 100% pure goodness.  You 
revisionist!

DO NOT REPLY [Bug 17927] New: - junitreport

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

junitreport

   Summary: junitreport
   Product: Ant
   Version: 1.5.2
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]

DO NOT REPLY [Bug 17927] - junitreport

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

junitreport





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 18:23 ---
Ingore this

RE: enhanced pvcs task for PVCS version 7.5

[cp533]

Thanks! I think, I get it now.

Most of the time, I work with the support team to sort any issues, I was
not aware (that's what the support team wants) of the inside details. I
just have looked at the docs for old(just to differentiate from pcli)  pvcs
commands, that goes like this for configuration files

Version Manager has a prescribed order in which it searches for
configuration files. Version Manager first reads the configuration
file that is embedded in the VCONFIG files (this is usually the
master configuration file).
The most direct way to specify a configuration file is to use a
command's -c option.
If you don't specify a configuration file using this option, Version
Manager checks for a default configuration file (named vcs.cfg)
in the current directory. If this file does not exist, Version
Manager checks for the VCSCFG environment variable, which
specifies the name and location of the configuration file to use.


I happen to have the VCSCFG set in my profile, that is why I did not have
problem with old get, even when I use with promotion group.

Hope this helps...

Chandra Periyaswamy
MPI - Incentives
tie-line: 754-5328
email: [EMAIL PROTECTED]



   
  "Anderson, Rob  H 
   
  - VSCM"  To:   "'Ant Developers 
List'" <[EMAIL PROTECTED]>  
  <[EMAIL PROTECTED]cc: 

  torscm.com>  Subject:  RE: enhanced pvcs task 
for PVCS version 7.5   

   
  03/12/2003 12:47  
   
  PM
   
  Please respond to 
   
  "Ant Developers   
   
  List" 
   

   

   




Apparently there is some confusion around repository and config file. I
apologize for not being very clear about this. Let me explain. By default,
when you create a Version Manager project database a config file is created
in the archives directory. You can see the config file name and location
through the GUI if you right click the project database and choose
"Properties". You can, however, specify a config file to use when you
create
the project database (in the advanced tab) or at any time through the
"Properties" dialog. For example: I have a local repository that I created
using the defualts ("Create a new config file" in the Advanced tab) for a
config file. The layout is as follows;

Project Database (-pr)
c:\pvcs
Config file
c:\pvcs\archives\cos0nbu1.cfg

I have a shared project database that was created with a custom config file
("Use an existing configuration file" in the Advanced tab)

Project Database (-pr)
s:\Projects\NOONAN
Config File
s:\configuration files\NOONAN.cfg

In both cases, using get works fine without the -c option unless I am doing
a get by promotion group. When doing a get by promotion group I will get an
error that says "get: Group "CM" does not exist in promotion hierarchy.",
because the promotion model is defined in the config file. So, if I specify
the config file with the -c option, this error goes away and the get by
promotion group works as expected.

So using the pvcs task is no different. Doing a normal "get" works fine,
but
a "get by promotion group" fails with the error mentioned above. If there
was a configfile attribute to the pvcs task I could use it to get by
promotion group. Currently I can only use it to do a "get the default
revision". Does this make sense?

-Rob A


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 3:22 PM
To: Ant Developers List
Subject: RE: enhanced pvcs task for PVCS version 7.5




PVCS task works with version 7.5 as is, unless you are pointing to a config
file other than the d

Feature request: Ignore attributes and elements from foreign namespaces

[Herr Christian Wolfgang Hujer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello dear Ant developers,

I have a suggestion to improve the Syntax of build.xml.
Attributes and elements from foreign namespaces should be ignored.
That way it would e.g. be possible to write a build xml like this:
http://www.w3.org/2003/cvs";
>



Currently, Ant complains about the xmlns:cvs and cvs:Header attributes, it 
doesn't recognize namespaces at all.


What do you think?

If I'm not the only one requesting that feature, I'll file a feature request 
report in Bugzilla.


Bye
- --
ITCQIS GmbH
Christian Wolfgang Hujer
GeschÃftsfÃhrender Gesellschafter
Telefon: +49  (0)89  27 37 04 37
Telefax: +49  (0)89  27 37 04 39
E-Mail: [EMAIL PROTECTED]
WWW: http://www.itcqis.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+b5LGzu6h7O/MKZkRAnCAAKCW2nTAJP8Q37iB3IOtNuI/vsPaGQCfaLpy
DlK+rLAVi8LG80OoPfXg9X8=
=plfX
-END PGP SIGNATURE-

DO NOT REPLY [Bug 17934] New: - Dates too late in jar entries

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

Dates too late in jar entries

   Summary: Dates too late in jar entries
   Product: Ant
   Version: 1.5.2
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In 1.5.2, the times on the JarEntries for jar files built with the Jar task are
rounded up instead of down.  When used with, e.g., Weblogic's jspc, this results
in the jsps in the jar file being later than the date compiled into the jsp java
code, and thus the compiled jsps are ignored.  The end result is that when I
build with ant 1.5.2, precompiled jsps are ignored by Weblogic.

I can see in the code on line 960 of
ant/src/main/org/apache/tools/ant/taskdefs/Zip.java, tag ANT_152_FINAL, that
1999 milliseconds are being added to the modification date.  ANT_151_FINAL
doesn't do this.  It appears to me that this is causing the problem.

Strangely, we put a sleep in before the jspc task in our ant script and it still
doesn't fix the out of date issue that we're having.  The only workaround we
have is to use 1.5.1 for now.

Re: Feature request: Ignore attributes and elements from foreign namespaces

[Conor MacNeill]

On Thu, 13 Mar 2003 07:04 am, Herr Christian Wolfgang Hujer wrote:
> Hello dear Ant developers,
>
>
> Currently, Ant complains about the xmlns:cvs and cvs:Header attributes, it
> doesn't recognize namespaces at all.
>

Try Ant 1.6 alpha from CVS or a nightly build.

-- 
Conor MacNeill
Blog: http://codefeed.com/blog/

Possible TaskDef donation

[Berin Loritsch]

Currently, if you want to support the JAR Services standard set forth
by Sun, you have to create a file with an interface name in
META-INF/services and list all the implementations.
This can get to become a problem if we are adding and removing classes,
and we forget to update this hand maintained file.
I wrote an ANT task that will scan an existing JAR, and find all the
classes that implement the specified interfaces.  The task verifies
that the supplied service name *is* in fact an interface, and then
it checks every class in the JAR to see if it implements that interface.
After it collects all this information it adds a new entry for each
interface, with the list of implementations for each service.
For now it needs to use an input jar and an output jar because I could
not figure out how to modify the jar in place.
As more project adopt this standard, it would be nice to include in
ANT proper.
If you are interested, I can post the source code.

DO NOT REPLY [Bug 17871] - war task's webxml attrib no longer is able to use value with a starting backslash for the path in Windows

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

war task's webxml attrib no longer is able to use value with a starting 
backslash for the path in Windows





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 22:28 ---
I can confirm the existence of this bug.


I have done a test of this bug under Win2000 and  JDK 1.4.1_01-b01


I think I also have found the origin of this bug :


1)War.java#zipFile(File file, ZipOutputStream zOut, String vPath, 


   int mode)


contains a line saying ... !deploymentDescriptor.equals(file) ...


in test3 deploymentDescriptor = \Xxx\Yyy\Zzz.xml


 file = D:\Xxx\Yyy\Zzz.xml


therefore War.java#zipFile refuses to include \Xxx\Yyy\Zzz.xml into the war file






2) AbstractFileSet.java does this


   public void setFile(File file) {


...


setDir(fileUtils.getParentFile(file));


...


}


getParentFile returns D:\Xxx\Yyy\ always, independently of whether file 
contains 
the drive specification or not

DO NOT REPLY [Bug 17871] - war task's webxml attrib no longer is able to use value with a starting backslash for the path in Windows

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

war task's webxml attrib no longer is able to use value with a starting 
backslash for the path in Windows





--- Additional Comments From [EMAIL PROTECTED]  2003-03-12 22:38 ---
Created an attachment (id=5298)
fixes the problem in War.java

1.6 milestones ?

[Costin Manolache]

Hi, 

Do we have any plan or idea on when we'll start distributing 1.6 milestone
builds ?

Tomcat5 is getting stable, and the next milestone will probably include an
"embeded" profile that will be controlled by ant and jmx tasks. It would
really help to have a matching ant1.6M1 instead of requiring a head build.

I can't volunteer as release manager - and I don't want to push anyone
or anything, just want to get an idea about what to expect, so I either
remove deps on 1.6 or move ahead. Right now I'm only using ,
but I'll probably use import ( and I would use 1.6 for the improvements in
startup time )

Costin

Re: Feature request: Ignore attributes and elements from foreign namespaces

[Herr Christian Wolfgang Hujer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

Am Mittwoch, 12. MÃrz 2003 23:18 schrieb Conor MacNeill:
> On Thu, 13 Mar 2003 07:04 am, Herr Christian Wolfgang Hujer wrote:
> > Hello dear Ant developers,
> >
> >
> > Currently, Ant complains about the xmlns:cvs and cvs:Header attributes,
> > it doesn't recognize namespaces at all.
>
> Try Ant 1.6 alpha from CVS or a nightly build.

okay, just did a cvs checkout, bootstrapped it and use Ant 1.6 alpha now. 
xmlns:cvs is accepted, but cvs:Header is still rejected.

So my feature request that Ant should ignore attributes and elements from 
foreign namespaces stays. Attributes from foreign namespaces should be 
ignored everywhere, elements from foreign namespaces should be ignored at 
least in elements like .


Bye
- -- 
ITCQIS GmbH
Christian Wolfgang Hujer
GeschÃftsfÃhrender Gesellschafter
Telefon: +49  (0)89  27 37 04 37
Telefax: +49  (0)89  27 37 04 39
E-Mail: [EMAIL PROTECTED]
WWW: http://www.itcqis.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+b8Ghzu6h7O/MKZkRAlbkAKDSWjP5+CbHPXSHPC+YA+LLZTtIVACfVrsp
bSzfJXM2rtYs5qIvIC5l2qA=
=xS7V
-END PGP SIGNATURE-

RE: sql triggers, stored procedures, packages, format preserved

[Anderson, Rob H - VSCM]

Pretty please :)

-Original Message-
From: Anderson, Rob H - VSCM [mailto:[EMAIL PROTECTED]
Sent: Monday, March 10, 2003 1:27 PM
To: '[EMAIL PROTECTED]'
Subject: sql triggers, stored procedures, packages, format preserved


Committers, Can we get this in the next release? Please :) I guess we will
need to update the documentation for the sql task also. 

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10719

Robert Anderson
Software Configuration Management
Vector SCM
503-450-6514
[EMAIL PROTECTED]


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

Re: 1.6 milestones ?

[Steve Loughran]

- Original Message -
From: "Costin Manolache" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 12, 2003 14:50
Subject: 1.6 milestones ?


> Hi,
>
> Do we have any plan or idea on when we'll start distributing 1.6 milestone
> builds ?
>
> Tomcat5 is getting stable, and the next milestone will probably include an
> "embeded" profile that will be controlled by ant and jmx tasks. It would
> really help to have a matching ant1.6M1 instead of requiring a head build.
>
> I can't volunteer as release manager - and I don't want to push anyone
> or anything, just want to get an idea about what to expect, so I either
> remove deps on 1.6 or move ahead. Right now I'm only using ,
> but I'll probably use import ( and I would use 1.6 for the improvements in
> startup time )

That's the  task that doesnt have any documentation, right?

Maybe the thing to do is look at what major changes still need to go in to
ant. Now that we have exploded optional.jar, we need to compensate by
perhaps adding a boot loader process for running ant, so that win9x boxes
dont run out of memory. We also need to rework the documentation.

The other feature I thought was on the cards was some kind of plugin
mechanism that pulls in new jars better -presumably a manifest, and the
appropriate extensions to  to handle them.

I think together these would be core features that need to be up and running
before we can worry about milestone releases.

Re: sql triggers, stored procedures, packages, format preserved

[Steve Loughran]

can we have the patch as diff -u then ?

- Original Message -
From: "Anderson, Rob H - VSCM" <[EMAIL PROTECTED]>
To: "'Ant Developers List'" <[EMAIL PROTECTED]>
Sent: Wednesday, March 12, 2003 15:36
Subject: RE: sql triggers, stored procedures, packages, format preserved


> Pretty please :)
>
> -Original Message-
> From: Anderson, Rob H - VSCM [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 10, 2003 1:27 PM
> To: '[EMAIL PROTECTED]'
> Subject: sql triggers, stored procedures, packages, format preserved
>
>
> Committers, Can we get this in the next release? Please :) I guess we will
> need to update the documentation for the sql task also.
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10719
>
> Robert Anderson
> Software Configuration Management
> Vector SCM
> 503-450-6514
> [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]
>
>