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
