[GRADLE-388] A mechanism to allow debugging of compile or test code with a simple command line option Created: 06/Feb/09 Updated: 10/Feb/17 Resolved: 10/Feb/17 |
|
Status: | Resolved |
Project: | Gradle |
Affects Version/s: | 0.2, 0.3, 0.4, 0.5, 0.5.1, 0.5.2 |
Fix Version/s: | None |
Type: | New Feature | ||
Reporter: | Mattthew Fudge | Assignee: | Unassigned |
Resolution: | Won't Fix | Votes: | 0 |
Description |
A mechanism to allow debugging of compile time and test time code (especially test time code in subprojects). Test time so that you can drop into a debugger to trace through the failing test cases. I believe that by default the test cases are run in thier own vm (fork==true) Compile time as often code generators or such like do not behave as expected and it can be very helpful to debug in to this code to find out what you have done wrong (no fork here so you should be able to debug anything that is running as part of the gradle build) The original question was : |
Comments |
Comment by Mattthew Fudge [ 06/Feb/09 ] |
Perhaps a config option in the settings or build file at the top level that specifies the debuging options but is only used when an optional "-Ddebug.test" or "-Ddebug.source" option is specified. And perhaps an option in the ~/.gradle that overrides that. |
Comment by Hans Dockter [ 13/Mar/09 ] |
This is a very good idea but hard to implement with our current test implementation. With 0.7 we want to provide a native test runner (we use ant-junit at the moment). This test runner would provide listener hooks (also across JVM's). Those hooks can be used for progress reporting or getting debug output. Something similar should be provided for compile. Then it would be also easy to provide command line options to control this behavior. |
Comment by Hans Dockter [ 22/Jun/10 ] |
The test task now has a debug property. You can't set this from the command line ATM. Setting task properties from the command line will become a generic feature in 1.0. |
Comment by Benjamin Muschko [ 15/Nov/16 ] |
As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub. We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to. Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:
We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle! |
Comment by Benjamin Muschko [ 10/Feb/17 ] |
Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved. |