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 <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 > >
