ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: Command Line Debugging
Date Thu, 16 Jun 2011 17:46:07 GMT
On Thu, Jun 16, 2011 at 12:37 PM, Siddhartha Purkayastha
<kpsiddharth@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 <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
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message