On Thu, Jun 16, 2011 at 12:37 PM, Siddhartha Purkayastha <kpsiddha...@gmail.com> wrote: > 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? >
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. Correct again. > (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 hadn't considered this. > > 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? Strictly speaking, it isn't 100% necessary to use the PropertyHelperTask to replace the PropertyHelper. However, in my experience it's not something you can do with stock Ant tasks, instead requiring Java (or, I suppose, script) code to do. So why would anyone *not* use the provided task to do it? Therefore this seems reasonable. Matt > > 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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
