ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siddhartha Purkayastha <kpsiddha...@gmail.com>
Subject Re: Command Line Debugging
Date Wed, 15 Jun 2011 18:24:37 GMT
I had missed removing it - the patch is not required now. Removed it from
svn.

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, the
> > 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 on
> > 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-line-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 choice
> 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 edited.
> >
> > Can you share thoughts on this? Can we include other things to make this
> > 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 with
> 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 any
> >> debug-APIs from Ant would be of use to them.
> >>
> >> Any thoughts?
> >>
> >> Thanks,
> >> Siddhartha
> >>
> >>
> >> On 10 June 2011 10:55, Jan Matèrne <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"
> >>>
> >>> ==> Eclipse changed to the debug perspective (or wants to)
> >>> In the variables view you can see the properties, but not change values
> or
> >>> set new props.
> >>>
> >>>
> >>> Jan
> >>>
> >>> > -----Ursprüngliche 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ée wrote:
> >>> > > At some point we may imagine a debugger in an IDE like Eclipse
too.
> >>> >
> >>> > 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message