Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (nike.apache.org: domain of kpsiddharth@gmail.com
 designates 209.85.214.45 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=qMfBbqT+H0kZutOTDUMxBbVIeM0HGIFxgMGFf8LscO7IteZtwIhMnfelWYLXzuzL8K
         doYK8ZWJ6jyvOflZXAaz7HKa6XhQ/hWfywECqgEBpxGcgT5Qm6jD4kdIkTTULl08Kg9D
         DK8WJWlsGe7stNea+WnMCs6vjpKoZds7sZMV4=
MIME-Version: 1.0
In-Reply-To: <BANLkTinnaEyJJiyYfsWHLrx4k76gcqxnTA@mail.gmail.com>
References: <247CFBCA82AE4D4A91B0337967B582800175B518@INHYMS12.ca.com>
	<BANLkTimHH4qBMqcgGrZvNTNKCCgZ86usJg@mail.gmail.com>
	<247CFBCA82AE4D4A91B0337967B582800175B544@INHYMS12.ca.com>
	<01BEE39B-39AC-4D41-AE53-E3BD255048CA@hibnet.org>
	<isr7mf$f9j$1@dough.gmane.org>
	<003801cc272e$d6206d50$826147f0$@de>
	<BANLkTikAKxi5iLEk0RoGAkOmqTf06B9B_Q@mail.gmail.com>
	<BANLkTi=eNX8aGJ=gj3BnyAA75QkOXCdnMQ@mail.gmail.com>
	<BANLkTinnaEyJJiyYfsWHLrx4k76gcqxnTA@mail.gmail.com>
Date: Thu, 16 Jun 2011 23:07:48 +0530
Message-ID: <BANLkTi=Ri_OC77LKm1N4fh9T03tOze1u+Q@mail.gmail.com>
Subject: Re: Command Line Debugging
From: Siddhartha Purkayastha <kpsiddharth@gmail.com>
To: Ant Developers List <dev@ant.apache.org>
Content-Type: multipart/alternative; boundary=bcaec52c69ab4a32a004a5d7baec

--bcaec52c69ab4a32a004a5d7baec
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Matt,

I am not sure I understand the whole of what you said (probably I lack
sufficient context here), so I am trying to rephrase here -

What you are suggesting is we defer the creation of the PropertyDebugHelper
(our custom helper) till the execution of the "" target (which I assume is
the implicit target) is complete. The assumption being that we may expect a
custom propertyhelper, if available at all, to have been instantiated by
then. If there is such a propertyhelper it will be wrapped by the
PropertyDebugHelper instance and all that the latter would do is to do its
own stuff and then delegate the call to the actual wrapped helper. Is this
correct?

If so, I see two problems with this:

(a) It seems it is also possible to create propertyhelpers inside
user-defined targets - in which case we will not be able to track such
property helpers? May be that is why you brought up the question of
listeners for the project references table.
(b) If the creation of the PropertyDebugHelper is deferred till later we
will not be able to define watch points on property creations that are
happening in the "" target.

I think another way of attaining it could be to 'indirectly listen' for
calls to set a PropertyHelper instance in the taskFinished method of the
listener itself. As soon as we detect a call to the propertyhelper task has
finished, we can retrieve the new PropertyHelper, replace the existing
wrapped instance in PropertyDebugHelper with the new one, and set this
PropertyDebugHelper instance back as the PropertyHelper reference for the
project.

How does this sound?

Thanks,
Siddhartha

On 15 June 2011 23:48, Matt Benson <gudnabrsam@gmail.com> wrote:

> On Wed, Jun 15, 2011 at 12:53 PM, Siddhartha Purkayastha
> <kpsiddharth@gmail.com> wrote:
> > Hello All -
> >
> > I spent some more time on this and have enhanced the POC to include the
> > following (in addition to moving to a listener based model as suggested
> by
> > Nicolas):
> >
> > (a) Added Property Watchpoints: You could specify a property which will
> be
> > monitored for attempted changes, and when such a change is detected, th=
e
> > execution is paused, and the user is presented the debug prompt.
> > (b) Added provision to add multiple break points and watch points at
> runtime
> > through the debug prompt itself instead of command line arguments. When
> you
> > launch ant using the debug tool, you get a prompt on BuildStarted event
> > where you can add all breakpoints.
> > (c) Added an Auditor that monitors and collects all changes attempted o=
n
> > select properties and lists the 'attempted change' audit records on
> request.
> > Such a property must have been earlier added as a watchpoint.
> >
> > The implementation may be found here:
> >
> https://svn.apache.org/repos/asf/incubator/easyant/tasks/trunk/command-li=
ne-debuggeralong
> > with Ant and EasyAnt build files.
> >
> > There is a README file checked in this location: please refer this for
> usage
> > - trying it is very easy - it should take just two steps.
> >
> > If you will take a look at the code, I have substituted the regular
> > PropertyHelper with a debugger version to implement watchpoints. It
> appears
> > on second thoughts that a PropertyHelper Delegate may be a better choic=
e
> to
> > attain this but, I am not sure. Can someone help on this?
> >
>
> Actually, since delegates can be added at will and are consulted in
> LIFO order, a delegate wouldn't ensure that the debug delegate always
> preempts every other.  I think the custom PropertyHelper is the way to
> go.  To be completely bullet-proof I would think eventually we need to
> finish the TODO in oata.Project of making the reference table
> listenable/interceptable; this way the PropertyDebugHelper can always
> delegate back to another instance and you can always wrap any incoming
> PropertyHelper.  For now I would recommend you go ahead and set the
> PropertyHelper up for delegation as I have said, then do your setup
> after the "" target completes rather than when the build starts; this
> way you can attempt to work with users' custom PropertyHelpers.  If
> you really wanted to get fancy you could dynamically generate proxies
> for their custom PropertyHelper types so that their casts, if any,
> would still succeed, but at some point you have to draw the line, I
> suppose.  :)
>
> I notice the Ant patches in svn; are those still necessary?  I would
> imagine that if done correctly, most of what you need does not require
> debug awareness in Ant core--even the change I mentioned above isn't
> about debugging per se, just reference tracking.
>
> Regards,
> Matt
>
> > I am imagining the following additions to this tool:
> > (a) Adding Exception Breakpoints: If a task throws an exception of
> interest,
> > then the debug mode takes over.
> > (b) Allowing Properties to be set/unset, and probably paths to be edite=
d.
> >
> > Can you share thoughts on this? Can we include other things to make thi=
s
> > more useful?
> >
> > Thanks,
> > Siddhartha
> >
> > On 10 June 2011 16:17, Siddhartha Purkayastha <kpsiddharth@gmail.com>
> wrote:
> >
> >> Hi Nicolas - BuildListener is a better idea than my current
> implementation.
> >> It looks cleaner and perhaps the same listener can also be attached at
> >> individual task level to step through targets one by one, pausing at
> each
> >> one. I will try to incorporate your comments and share the outcome wit=
h
> the
> >> group.
> >>
> >> Hi Jan / Jesse - If you would have noticed, the PoC allows detecting
> >> current values of properties, and paths, and also the location of
> individual
> >> properties inside build files. I think it should also be possible to
> locate
> >> individual tasks. Do you have any suggestions on what else can be
> included
> >> into this to make it more helpful?
> >>
> >> A further thought - It could also be possible to expose the listener
> itself
> >> (or any such debugging interface) as a hook from within Ant, that IDEs
> can
> >> use to implement any debuggers. If the developers of any debuggers are
> >> present here and can help, then they could share their approach - or a=
ny
> >> debug-APIs from Ant would be of use to them.
> >>
> >> Any thoughts?
> >>
> >> Thanks,
> >> Siddhartha
> >>
> >>
> >> On 10 June 2011 10:55, Jan Mat=E8rne <apache@materne.de> wrote:
> >>
> >>> Eclipse (tested with Helios) has a built in Ant debugger too.
> >>> Quick test:
> >>> - write a buildfile
> >>> - set a breakpoint (line 9)
> >>> - "Debug as > Ant build"
> >>>
> >>> =3D=3D> Eclipse changed to the debug perspective (or wants to)
> >>> In the variables view you can see the properties, but not change valu=
es
> or
> >>> set new props.
> >>>
> >>>
> >>> Jan
> >>>
> >>> > -----Urspr=FCngliche Nachricht-----
> >>> > Von: Jesse Glick [mailto:jesse.glick@oracle.com]
> >>> > Gesendet: Donnerstag, 9. Juni 2011 21:42
> >>> > An: dev@ant.apache.org
> >>> > Betreff: Re: Command Line Debugging
> >>> >
> >>> > On 06/09/2011 05:42 AM, Nicolas Lalev=E9e wrote:
> >>> > > At some point we may imagine a debugger in an IDE like Eclipse to=
o.
> >>> >
> >>> > By the way there has long been an Ant debugger in NetBeans. Just
> select
> >>> > Debug Target from the context menu of a build script in e.g. the
> Files
> >>> > tab. Breakpoints and
> >>> > property inspection are supported.
> >>> >
> >>> >
> >>> > -------------------------------------------------------------------=
--
> >>> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> >>> > For additional commands, e-mail: dev-help@ant.apache.org
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> >>> For additional commands, e-mail: dev-help@ant.apache.org
> >>>
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>

--bcaec52c69ab4a32a004a5d7baec--