You are viewing a plain text version of this content. The canonical link for it is here.
Posted to easyant-dev@incubator.apache.org by Jean-Louis Boudart <je...@gmail.com> on 2011/06/06 15:39:09 UTC
Re: Command Line Debugging
The idea really looks like promising.
I think this feature could have a better place in ant itself (i'm adding
them in copy of this email).
Could you share the code of your POC somewhere with some guide line to test
it? I'm pretty sure people will have ideas when they will try it. If you
need a place to publish it you can use this :
https://svn.apache.org/repos/asf/incubator/easyant/tasks/trunk/.
2011/5/29 Purkayastha, Siddhartha <Si...@ca.com>
> Hello All -
>
> I wanted to discuss an idea with you about diagnostics. When considering
> about diagnostics, it should comprise of a set of tools that can help me
> diagnose issues I am facing with my build. Ant -diagnostics returns lots of
> variables that can be valuable to resolving environment / setup issues.
>
> I am thinking of the possibility of a Command Line Debugger / Inspector
> included within EasyAnt (or may be even Ant itself). I am not aware if such
> a tool already exists.
>
> It could behave something like this:
> I can run:
> ant -breakAt=someTarget
>
> The breakAt parameter could indicate a breakpoint at target 'someTarget'.
> The user could be interactively displayed a prompt here:
> breakpoint:
> [Debugger] DEBUGGER>
>
> Where the user could issue a set of commands to inspect the state of the
> build so far.
>
> For example:
> breakpoint:
> [Debugger] DEBUGGER> inspect some.property
> Property Value: HelloWorld
>
> The same idea could be extended to include other build factors, like paths,
> imported plugins etc. It may actually be extended to become a fully featured
> command line debugger, from where one can also set new property values or
> override existing values (probably a relaxation of immutability for the
> support of this tool) etc, do step over, step into etc.
>
> I did some experiments with this concept, I was able to break at a certain
> target and inspect values of properties that user wants to see, using a new
> target created at Runtime, with a single task that accepted user inputs from
> command line, interpreted it and displayed an output - And kept on doing so
> till the user typed 'return' on the prompt. I also think, as an extension -
> if we can also track audit history of different properties, paths,
> references etc, then this could be an effective tool. However, I do not
> think it is easily achievable today.
>
> I am wondering about the technical feasibility and utility of such an
> inbuilt tool. Can you share your thoughts on this?
>
> Thanks,
> Siddhartha
>
--
Jean Louis Boudart
Independent consultant
Project Lead http://www.easyant.org
Re: Command Line Debugging
Posted by Siddhartha Purkayastha <kp...@gmail.com>.
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 <gu...@gmail.com> wrote:
> On Wed, Jun 15, 2011 at 12:53 PM, Siddhartha Purkayastha
> <kp...@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 <kp...@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 <ap...@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
>
>
Re: Command Line Debugging
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 16 juin 2011 à 19:46, Matt Benson a écrit :
> On Thu, Jun 16, 2011 at 12:37 PM, Siddhartha Purkayastha
> <kp...@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.
Or instead of monitoring the execution of the task PropertyHelperTask, you can simply check that after each task execution the current property helper is still the wrapped one. If not the wrapped one, then wrap it. It should be cpu costless as a simple comparison of pointers should be enough.
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Command Line Debugging
Posted by Matt Benson <gu...@gmail.com>.
On Thu, Jun 16, 2011 at 12:37 PM, Siddhartha Purkayastha
<kp...@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 <gu...@gmail.com> wrote:
>
>> On Wed, Jun 15, 2011 at 12:53 PM, Siddhartha Purkayastha
>> <kp...@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 <kp...@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 <ap...@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
Re: Command Line Debugging
Posted by Siddhartha Purkayastha <kp...@gmail.com>.
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 <gu...@gmail.com> wrote:
> On Wed, Jun 15, 2011 at 12:53 PM, Siddhartha Purkayastha
> <kp...@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 <kp...@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 <ap...@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
>
>
Re: Command Line Debugging
Posted by Matt Benson <gu...@gmail.com>.
On Wed, Jun 15, 2011 at 12:53 PM, Siddhartha Purkayastha
<kp...@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 <kp...@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 <ap...@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
Re: Command Line Debugging
Posted by Siddhartha Purkayastha <kp...@gmail.com>.
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?
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 <kp...@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 <ap...@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
>>
>>
>
Re: Command Line Debugging
Posted by Siddhartha Purkayastha <kp...@gmail.com>.
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 <ap...@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
>
>
AW: Command Line Debugging
Posted by Jan Matèrne <ap...@materne.de>.
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
Re: Command Line Debugging
Posted by Jesse Glick <je...@oracle.com>.
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
Re: Command Line Debugging
Posted by Nicolas Lalevée <ni...@hibnet.org>.
This is looking great ! At some point we may imagine a debugger in an IDE like Eclipse too. This seems a nice first step.
About the implementation, I think you don't need to patch ant for that. At least for a first POC.
If you implement a listener (see org.apache.tools.ant.BuildListener), I think you will be able to pause the execution of the targets.
Then rather than adding some new command line argument, you could setup some "magic" ant property. For instance "ant.debugger.target".
So the command line could look line:
ant -listener org.apache.ant.debugger.DebuggerListener -Dant.debugger.target=mypausedtarget
Then if the ant developer community likes it, we could modify ant Main class to add a new command line option which will be a shortcut for the above arguments.
Nicolas
Le 7 juin 2011 à 11:40, Purkayastha, Siddhartha a écrit :
> Hello -
>
> In case you have not had an occassion to go through the original mail, the idea is to build a command line utility that will allow the user to pause the build execution (similar to a break-point), and allow the user to inspect the status of the build. For example, what is the value of a property, what is the value of a path, where do I find the declaration of a property a.b.c.
>
> The sources for the POC may be found at this location:https://svn.apache.org/repos/asf/incubator/easyant/tasks/trunk/command-line-debugger. The patch sub-directory has a patch of the implementation.
>
> You could try this on the Ant build.xml itself. Something like this:
> ant -breakAt dist-lite
>
> The build pauses and presents a prompt to the end user asking for a command to run. Here are somethings you could try:
> locate property some.property: Should give you the declaration of the property inside the build file
> inspect property some.property: Should give you the current value of the property
> inspect path some.path: Should give you the current value of the path
> return: Returns from the prompt and resumes the build
>
> Here is a sample output from a run of my local setup:
> :
> test-jar:
> [jar] Building jar: D:\sandboxes\ant-svn\build\lib\ant-testutil.jar
> -internal-debugger:
>
> -------- Ant Command Line Debugger --------
>
> [Debugger] DEBUGGER>
> locate property Name
> Detected a property by name [Name]. Build file value: Apache Ant
> Located at: D:\sandboxes\ant-svn\build.xml:33:
>
> [Debugger] DEBUGGER>
> inspect property tests-classpath
> Found no such property.
>
> [Debugger] DEBUGGER>
> inspect path tests-classpath
> [pathconvert] D:\sandboxes\ant-svn\build\classes
> [pathconvert] - D:\sandboxes\ant-svn\lib\optional\ant-antunit-1.1.jar
> [pathconvert] - D:\sandboxes\ant-svn\lib\optional\junit-3.8.2.jar
> [pathconvert] - D:\sandboxes\ant-svn\lib\optional\junit-4.8.1.jar
>
> [Debugger] DEBUGGER>
>
> --------- Resuming Ant Execution ----------
>
> What do you think about the utility of such a tool?
>
> Thanks,
> Siddhartha
>
> ________________________________
>
> From: Jean-Louis Boudart [mailto:jeanlouis.boudart@gmail.com]
> Sent: Mon 6/6/2011 9:09 PM
> To: easyant-dev@incubator.apache.org; Ant Developers List
> Subject: Re: Command Line Debugging
>
>
>
> The idea really looks like promising.
>
> I think this feature could have a better place in ant itself (i'm adding
> them in copy of this email).
> Could you share the code of your POC somewhere with some guide line to test
> it? I'm pretty sure people will have ideas when they will try it. If you
> need a place to publish it you can use this :
> https://svn.apache.org/repos/asf/incubator/easyant/tasks/trunk/.
>
>
>
> 2011/5/29 Purkayastha, Siddhartha <Si...@ca.com>
>
>> Hello All -
>>
>> I wanted to discuss an idea with you about diagnostics. When considering
>> about diagnostics, it should comprise of a set of tools that can help me
>> diagnose issues I am facing with my build. Ant -diagnostics returns lots of
>> variables that can be valuable to resolving environment / setup issues.
>>
>> I am thinking of the possibility of a Command Line Debugger / Inspector
>> included within EasyAnt (or may be even Ant itself). I am not aware if such
>> a tool already exists.
>>
>> It could behave something like this:
>> I can run:
>> ant -breakAt=someTarget
>>
>> The breakAt parameter could indicate a breakpoint at target 'someTarget'.
>> The user could be interactively displayed a prompt here:
>> breakpoint:
>> [Debugger] DEBUGGER>
>>
>> Where the user could issue a set of commands to inspect the state of the
>> build so far.
>>
>> For example:
>> breakpoint:
>> [Debugger] DEBUGGER> inspect some.property
>> Property Value: HelloWorld
>>
>> The same idea could be extended to include other build factors, like paths,
>> imported plugins etc. It may actually be extended to become a fully featured
>> command line debugger, from where one can also set new property values or
>> override existing values (probably a relaxation of immutability for the
>> support of this tool) etc, do step over, step into etc.
>>
>> I did some experiments with this concept, I was able to break at a certain
>> target and inspect values of properties that user wants to see, using a new
>> target created at Runtime, with a single task that accepted user inputs from
>> command line, interpreted it and displayed an output - And kept on doing so
>> till the user typed 'return' on the prompt. I also think, as an extension -
>> if we can also track audit history of different properties, paths,
>> references etc, then this could be an effective tool. However, I do not
>> think it is easily achievable today.
>>
>> I am wondering about the technical feasibility and utility of such an
>> inbuilt tool. Can you share your thoughts on this?
>>
>> Thanks,
>> Siddhartha
>>
>
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Project Lead http://www.easyant.org <http://www.easyant.org/>
>
>
Re: Command Line Debugging
Posted by Nicolas Lalevée <ni...@hibnet.org>.
This is looking great ! At some point we may imagine a debugger in an IDE like Eclipse too. This seems a nice first step.
About the implementation, I think you don't need to patch ant for that. At least for a first POC.
If you implement a listener (see org.apache.tools.ant.BuildListener), I think you will be able to pause the execution of the targets.
Then rather than adding some new command line argument, you could setup some "magic" ant property. For instance "ant.debugger.target".
So the command line could look line:
ant -listener org.apache.ant.debugger.DebuggerListener -Dant.debugger.target=mypausedtarget
Then if the ant developer community likes it, we could modify ant Main class to add a new command line option which will be a shortcut for the above arguments.
Nicolas
Le 7 juin 2011 à 11:40, Purkayastha, Siddhartha a écrit :
> Hello -
>
> In case you have not had an occassion to go through the original mail, the idea is to build a command line utility that will allow the user to pause the build execution (similar to a break-point), and allow the user to inspect the status of the build. For example, what is the value of a property, what is the value of a path, where do I find the declaration of a property a.b.c.
>
> The sources for the POC may be found at this location:https://svn.apache.org/repos/asf/incubator/easyant/tasks/trunk/command-line-debugger. The patch sub-directory has a patch of the implementation.
>
> You could try this on the Ant build.xml itself. Something like this:
> ant -breakAt dist-lite
>
> The build pauses and presents a prompt to the end user asking for a command to run. Here are somethings you could try:
> locate property some.property: Should give you the declaration of the property inside the build file
> inspect property some.property: Should give you the current value of the property
> inspect path some.path: Should give you the current value of the path
> return: Returns from the prompt and resumes the build
>
> Here is a sample output from a run of my local setup:
> :
> test-jar:
> [jar] Building jar: D:\sandboxes\ant-svn\build\lib\ant-testutil.jar
> -internal-debugger:
>
> -------- Ant Command Line Debugger --------
>
> [Debugger] DEBUGGER>
> locate property Name
> Detected a property by name [Name]. Build file value: Apache Ant
> Located at: D:\sandboxes\ant-svn\build.xml:33:
>
> [Debugger] DEBUGGER>
> inspect property tests-classpath
> Found no such property.
>
> [Debugger] DEBUGGER>
> inspect path tests-classpath
> [pathconvert] D:\sandboxes\ant-svn\build\classes
> [pathconvert] - D:\sandboxes\ant-svn\lib\optional\ant-antunit-1.1.jar
> [pathconvert] - D:\sandboxes\ant-svn\lib\optional\junit-3.8.2.jar
> [pathconvert] - D:\sandboxes\ant-svn\lib\optional\junit-4.8.1.jar
>
> [Debugger] DEBUGGER>
>
> --------- Resuming Ant Execution ----------
>
> What do you think about the utility of such a tool?
>
> Thanks,
> Siddhartha
>
> ________________________________
>
> From: Jean-Louis Boudart [mailto:jeanlouis.boudart@gmail.com]
> Sent: Mon 6/6/2011 9:09 PM
> To: easyant-dev@incubator.apache.org; Ant Developers List
> Subject: Re: Command Line Debugging
>
>
>
> The idea really looks like promising.
>
> I think this feature could have a better place in ant itself (i'm adding
> them in copy of this email).
> Could you share the code of your POC somewhere with some guide line to test
> it? I'm pretty sure people will have ideas when they will try it. If you
> need a place to publish it you can use this :
> https://svn.apache.org/repos/asf/incubator/easyant/tasks/trunk/.
>
>
>
> 2011/5/29 Purkayastha, Siddhartha <Si...@ca.com>
>
>> Hello All -
>>
>> I wanted to discuss an idea with you about diagnostics. When considering
>> about diagnostics, it should comprise of a set of tools that can help me
>> diagnose issues I am facing with my build. Ant -diagnostics returns lots of
>> variables that can be valuable to resolving environment / setup issues.
>>
>> I am thinking of the possibility of a Command Line Debugger / Inspector
>> included within EasyAnt (or may be even Ant itself). I am not aware if such
>> a tool already exists.
>>
>> It could behave something like this:
>> I can run:
>> ant -breakAt=someTarget
>>
>> The breakAt parameter could indicate a breakpoint at target 'someTarget'.
>> The user could be interactively displayed a prompt here:
>> breakpoint:
>> [Debugger] DEBUGGER>
>>
>> Where the user could issue a set of commands to inspect the state of the
>> build so far.
>>
>> For example:
>> breakpoint:
>> [Debugger] DEBUGGER> inspect some.property
>> Property Value: HelloWorld
>>
>> The same idea could be extended to include other build factors, like paths,
>> imported plugins etc. It may actually be extended to become a fully featured
>> command line debugger, from where one can also set new property values or
>> override existing values (probably a relaxation of immutability for the
>> support of this tool) etc, do step over, step into etc.
>>
>> I did some experiments with this concept, I was able to break at a certain
>> target and inspect values of properties that user wants to see, using a new
>> target created at Runtime, with a single task that accepted user inputs from
>> command line, interpreted it and displayed an output - And kept on doing so
>> till the user typed 'return' on the prompt. I also think, as an extension -
>> if we can also track audit history of different properties, paths,
>> references etc, then this could be an effective tool. However, I do not
>> think it is easily achievable today.
>>
>> I am wondering about the technical feasibility and utility of such an
>> inbuilt tool. Can you share your thoughts on this?
>>
>> Thanks,
>> Siddhartha
>>
>
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Project Lead http://www.easyant.org <http://www.easyant.org/>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Command Line Debugging
Posted by "Purkayastha, Siddhartha" <Si...@ca.com>.
Hello -
In case you have not had an occassion to go through the original mail, the idea is to build a command line utility that will allow the user to pause the build execution (similar to a break-point), and allow the user to inspect the status of the build. For example, what is the value of a property, what is the value of a path, where do I find the declaration of a property a.b.c.
The sources for the POC may be found at this location:https://svn.apache.org/repos/asf/incubator/easyant/tasks/trunk/command-line-debugger. The patch sub-directory has a patch of the implementation.
You could try this on the Ant build.xml itself. Something like this:
ant -breakAt dist-lite
The build pauses and presents a prompt to the end user asking for a command to run. Here are somethings you could try:
locate property some.property: Should give you the declaration of the property inside the build file
inspect property some.property: Should give you the current value of the property
inspect path some.path: Should give you the current value of the path
return: Returns from the prompt and resumes the build
Here is a sample output from a run of my local setup:
:
test-jar:
[jar] Building jar: D:\sandboxes\ant-svn\build\lib\ant-testutil.jar
-internal-debugger:
-------- Ant Command Line Debugger --------
[Debugger] DEBUGGER>
locate property Name
Detected a property by name [Name]. Build file value: Apache Ant
Located at: D:\sandboxes\ant-svn\build.xml:33:
[Debugger] DEBUGGER>
inspect property tests-classpath
Found no such property.
[Debugger] DEBUGGER>
inspect path tests-classpath
[pathconvert] D:\sandboxes\ant-svn\build\classes
[pathconvert] - D:\sandboxes\ant-svn\lib\optional\ant-antunit-1.1.jar
[pathconvert] - D:\sandboxes\ant-svn\lib\optional\junit-3.8.2.jar
[pathconvert] - D:\sandboxes\ant-svn\lib\optional\junit-4.8.1.jar
[Debugger] DEBUGGER>
--------- Resuming Ant Execution ----------
What do you think about the utility of such a tool?
Thanks,
Siddhartha
________________________________
From: Jean-Louis Boudart [mailto:jeanlouis.boudart@gmail.com]
Sent: Mon 6/6/2011 9:09 PM
To: easyant-dev@incubator.apache.org; Ant Developers List
Subject: Re: Command Line Debugging
The idea really looks like promising.
I think this feature could have a better place in ant itself (i'm adding
them in copy of this email).
Could you share the code of your POC somewhere with some guide line to test
it? I'm pretty sure people will have ideas when they will try it. If you
need a place to publish it you can use this :
https://svn.apache.org/repos/asf/incubator/easyant/tasks/trunk/.
2011/5/29 Purkayastha, Siddhartha <Si...@ca.com>
> Hello All -
>
> I wanted to discuss an idea with you about diagnostics. When considering
> about diagnostics, it should comprise of a set of tools that can help me
> diagnose issues I am facing with my build. Ant -diagnostics returns lots of
> variables that can be valuable to resolving environment / setup issues.
>
> I am thinking of the possibility of a Command Line Debugger / Inspector
> included within EasyAnt (or may be even Ant itself). I am not aware if such
> a tool already exists.
>
> It could behave something like this:
> I can run:
> ant -breakAt=someTarget
>
> The breakAt parameter could indicate a breakpoint at target 'someTarget'.
> The user could be interactively displayed a prompt here:
> breakpoint:
> [Debugger] DEBUGGER>
>
> Where the user could issue a set of commands to inspect the state of the
> build so far.
>
> For example:
> breakpoint:
> [Debugger] DEBUGGER> inspect some.property
> Property Value: HelloWorld
>
> The same idea could be extended to include other build factors, like paths,
> imported plugins etc. It may actually be extended to become a fully featured
> command line debugger, from where one can also set new property values or
> override existing values (probably a relaxation of immutability for the
> support of this tool) etc, do step over, step into etc.
>
> I did some experiments with this concept, I was able to break at a certain
> target and inspect values of properties that user wants to see, using a new
> target created at Runtime, with a single task that accepted user inputs from
> command line, interpreted it and displayed an output - And kept on doing so
> till the user typed 'return' on the prompt. I also think, as an extension -
> if we can also track audit history of different properties, paths,
> references etc, then this could be an effective tool. However, I do not
> think it is easily achievable today.
>
> I am wondering about the technical feasibility and utility of such an
> inbuilt tool. Can you share your thoughts on this?
>
> Thanks,
> Siddhartha
>
--
Jean Louis Boudart
Independent consultant
Project Lead http://www.easyant.org <http://www.easyant.org/>
RE: Command Line Debugging
Posted by "Purkayastha, Siddhartha" <Si...@ca.com>.
Hello -
In case you have not had an occassion to go through the original mail, the idea is to build a command line utility that will allow the user to pause the build execution (similar to a break-point), and allow the user to inspect the status of the build. For example, what is the value of a property, what is the value of a path, where do I find the declaration of a property a.b.c.
The sources for the POC may be found at this location:https://svn.apache.org/repos/asf/incubator/easyant/tasks/trunk/command-line-debugger. The patch sub-directory has a patch of the implementation.
You could try this on the Ant build.xml itself. Something like this:
ant -breakAt dist-lite
The build pauses and presents a prompt to the end user asking for a command to run. Here are somethings you could try:
locate property some.property: Should give you the declaration of the property inside the build file
inspect property some.property: Should give you the current value of the property
inspect path some.path: Should give you the current value of the path
return: Returns from the prompt and resumes the build
Here is a sample output from a run of my local setup:
:
test-jar:
[jar] Building jar: D:\sandboxes\ant-svn\build\lib\ant-testutil.jar
-internal-debugger:
-------- Ant Command Line Debugger --------
[Debugger] DEBUGGER>
locate property Name
Detected a property by name [Name]. Build file value: Apache Ant
Located at: D:\sandboxes\ant-svn\build.xml:33:
[Debugger] DEBUGGER>
inspect property tests-classpath
Found no such property.
[Debugger] DEBUGGER>
inspect path tests-classpath
[pathconvert] D:\sandboxes\ant-svn\build\classes
[pathconvert] - D:\sandboxes\ant-svn\lib\optional\ant-antunit-1.1.jar
[pathconvert] - D:\sandboxes\ant-svn\lib\optional\junit-3.8.2.jar
[pathconvert] - D:\sandboxes\ant-svn\lib\optional\junit-4.8.1.jar
[Debugger] DEBUGGER>
--------- Resuming Ant Execution ----------
What do you think about the utility of such a tool?
Thanks,
Siddhartha
________________________________
From: Jean-Louis Boudart [mailto:jeanlouis.boudart@gmail.com]
Sent: Mon 6/6/2011 9:09 PM
To: easyant-dev@incubator.apache.org; Ant Developers List
Subject: Re: Command Line Debugging
The idea really looks like promising.
I think this feature could have a better place in ant itself (i'm adding
them in copy of this email).
Could you share the code of your POC somewhere with some guide line to test
it? I'm pretty sure people will have ideas when they will try it. If you
need a place to publish it you can use this :
https://svn.apache.org/repos/asf/incubator/easyant/tasks/trunk/.
2011/5/29 Purkayastha, Siddhartha <Si...@ca.com>
> Hello All -
>
> I wanted to discuss an idea with you about diagnostics. When considering
> about diagnostics, it should comprise of a set of tools that can help me
> diagnose issues I am facing with my build. Ant -diagnostics returns lots of
> variables that can be valuable to resolving environment / setup issues.
>
> I am thinking of the possibility of a Command Line Debugger / Inspector
> included within EasyAnt (or may be even Ant itself). I am not aware if such
> a tool already exists.
>
> It could behave something like this:
> I can run:
> ant -breakAt=someTarget
>
> The breakAt parameter could indicate a breakpoint at target 'someTarget'.
> The user could be interactively displayed a prompt here:
> breakpoint:
> [Debugger] DEBUGGER>
>
> Where the user could issue a set of commands to inspect the state of the
> build so far.
>
> For example:
> breakpoint:
> [Debugger] DEBUGGER> inspect some.property
> Property Value: HelloWorld
>
> The same idea could be extended to include other build factors, like paths,
> imported plugins etc. It may actually be extended to become a fully featured
> command line debugger, from where one can also set new property values or
> override existing values (probably a relaxation of immutability for the
> support of this tool) etc, do step over, step into etc.
>
> I did some experiments with this concept, I was able to break at a certain
> target and inspect values of properties that user wants to see, using a new
> target created at Runtime, with a single task that accepted user inputs from
> command line, interpreted it and displayed an output - And kept on doing so
> till the user typed 'return' on the prompt. I also think, as an extension -
> if we can also track audit history of different properties, paths,
> references etc, then this could be an effective tool. However, I do not
> think it is easily achievable today.
>
> I am wondering about the technical feasibility and utility of such an
> inbuilt tool. Can you share your thoughts on this?
>
> Thanks,
> Siddhartha
>
--
Jean Louis Boudart
Independent consultant
Project Lead http://www.easyant.org <http://www.easyant.org/>