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 <gudnabr...@gmail.com> wrote: > On Wed, Jun 15, 2011 at 12:53 PM, Siddhartha Purkayastha > <kpsiddha...@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 <kpsiddha...@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 <apa...@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.gl...@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-unsubscr...@ant.apache.org > >>> > For additional commands, e-mail: dev-h...@ant.apache.org > >>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > >>> For additional commands, e-mail: dev-h...@ant.apache.org > >>> > >>> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
