[GRADLE-2617] Some exception during plugin.apply() cant be eaten and don't break the build Created: 03/Jan/13 Updated: 17/Nov/16 Resolved: 17/Nov/16 |
|
| Status: | Resolved |
| Project: | Gradle |
| Affects Version/s: | 1.3 |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Xavier Ducrohet | Assignee: | Luke Daley |
| Resolution: | Duplicate | Votes: | 0 |
| Description |
|
Due to a broken Groovy refactor, my code ended up throwing a java.lang.IllegalAccessError from a method called from my plugin's apply(Project) method. I would expect this to stop gradle executing the build, but instead the exception ended up being eaten by the caller somehow and the build continued (and failed later in a weird way). |
| Comments |
| Comment by Xavier Ducrohet [ 03/Jan/13 ] |
|
oops. the title is wrong. Should read "... can be eaten ..." |
| Comment by Luke Daley [ 14/Jan/13 ] |
|
I cannot reproduce this with 1.3. Here is what I tried: class SomePlugin implements Plugin { void apply(project) { throw new java.lang.IllegalAccessError("!!") } } apply plugin: SomePlugin This fails in the expected way. If you can provide more information so that I can reproduce I'll happily reopen. |
| Comment by Xavier Ducrohet [ 14/Jan/13 ] |
|
Indeed when I run this snippet, it fails as expected, but with my own project it doesn't. It's open source so I could show you how to check it out and build it to see for yourself, but it's a bit involved. I'm going to try to make a reproducible case first. |
| Comment by Luke Daley [ 14/Jan/13 ] |
|
Hi Xavier, I'm happy to check out your failing code an reproduce it there. Please post some steps I can follow to reproduce. |
| Comment by Xavier Ducrohet [ 14/Jan/13 ] |
|
Hi Luke, I tried to extract what my plugin does to make a reproducible case it's not happening. I was looking at giving you all the steps to have you try it with my plugin but there's a dependency on an internal tools that should be removed in a few days. I'll let you know when you can try. thanks. |
| Comment by Luke Daley [ 15/Apr/13 ] |
|
Hi Xavier, Have you been able to reproduce this? |
| Comment by Xavier Ducrohet [ 02/May/13 ] |
|
Hi Luke, I haven't been able to reproduce though I just got something a bit similar (but not completely broken). My project has a configuration problem and the plugin throws a RuntimeException in the apply() method, after setting an afterEvaluate closure. What happens is that the afterEvaluate closure is executed even though apply() threw an exception. Of course it fails, and dumps an exception of its own, which gets dump in the terminal. This is a strange behavior, but at least the error message shows also the original error message from the apply error which makes the the exception dump is misleading at first). Here's the output: Failed to notify ProjectEvaluationListener.afterEvaluate(), but primary configuration failure takes precedence. FAILURE: Build failed with an exception.
|
| Comment by Luke Daley [ 07/May/13 ] |
|
> What happens is that the afterEvaluate closure is executed even though apply() threw an exception. This is not surprising. The closure you give to afterEvaluate() is a callback, and fires even if evaluation failed. You should check the project's state (http://www.gradle.org/docs/current/javadoc/org/gradle/api/Project.html#getState()) in your afterEvaluate callback and return if it's in a failed state. |
| Comment by Bruno Bowden [ 21/Nov/14 ] |
|
Hi Luke, |
| 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 Eric Wendelin [ 17/Nov/16 ] |