Return-Path: Delivered-To: apmail-ant-dev-archive@www.apache.org Received: (qmail 56335 invoked from network); 9 Apr 2005 01:06:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 9 Apr 2005 01:06:53 -0000 Received: (qmail 69358 invoked by uid 500); 9 Apr 2005 01:06:52 -0000 Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 69306 invoked by uid 500); 9 Apr 2005 01:06:52 -0000 Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list dev@ant.apache.org Received: (qmail 69291 invoked by uid 99); 9 Apr 2005 01:06:51 -0000 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=NO_REAL_NAME X-Spam-Check-By: apache.org Received: from ajax-1.apache.org (HELO ajax.apache.org) (192.87.106.226) by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 08 Apr 2005 18:06:50 -0700 Received: by ajax.apache.org (Postfix, from userid 99) id 4800B2CB; Sat, 9 Apr 2005 03:06:47 +0200 (CEST) From: bugzilla@apache.org To: dev@ant.apache.org Subject: DO NOT REPLY [Bug 34382] New: - Loss of Location information for sequential task of macrodef X-Bugzilla-Reason: AssignedTo Message-Id: <20050409010647.4800B2CB@ajax.apache.org> Date: Sat, 9 Apr 2005 03:06:47 +0200 (CEST) X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG� RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND� INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34382 Summary: Loss of Location information for sequential task of macrodef Product: Ant Version: 1.6.2 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Core AssignedTo: dev@ant.apache.org ReportedBy: Darin_Swanson@us.ibm.com With the creation of the NestedSequential representation of the nested sequential task of macrodef, the Location from the original sequential task is lost. Therefore when the MacroDef "fakes" out the new UnknownElement in getNestedTask () it is not possible for this element to have the correct Location as it cannot be passed on from the nestedSequential object. This comes into play for the Eclipse Ant debugger...the sequential task in the debugger stack trace always shows the unknown location. I would request that if possible changes be made to provide the location for the sequential task in this case. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org