This is cool stuff! Does anything change in a way instances of GradleException (or any exception that descends from GradleException) are presented in the failure summary?
+1 for removing the "Failed to notify action" from the failure list. Cheers! On Mon, Dec 17, 2012 at 11:35 PM, Daz DeBoer <[email protected]> wrote: > G'day > I've made some minor changes to the way build failures are reported, > so that more context is included in the "What went wrong:" section of > the build failure report. > > Entry point selection > ---------------------------- > Choosing a 'top-level' exception to report has not changed. As before, > we first find the "entry point" exception in the failure chain. This > is usually a GradleScriptException or TaskExecutionException, but in > some cases could be the 'deepest' exception marked with @Contextual. > > Failure summary > ----------------------- > Previously, we would simply report the entry point, it's direct cause, > and recursively report the nested cause for any exception that was > marked as @Contextual. So having a single non-contextual exception in > the chain meant that any 'deeper' contextual exceptions would not be > reported. > > The way it now work is: > 1) Report the entry point > 2) Descend the chain, reporting any exception(s) marked with @Contextual > 3) Report the direct cause of the last reportable exception. This will > be the direct cause of the 'deepest' @Contextual exception, or the > direct cause of the entry point. > > In practice this means that all @Contextual exceptions in the chain > will be reported, even if interspersed with non-contextual exceptions. > This makes reporting meaningful when using ActionBroadcast or other > similar infrastructure that may wrap the real exception. Previously > the ultimate cause was not reported in this case. > > UserCodeAction > ----------------------- > When a user supplies code that we execute as an Action, you can now > wrap the user-supplied action in a UserCodeAction. This simply wraps > any exception (often emitted by Groovy) in a UserCodeException, which > is given a sensible message and is marked @Contextual. > > An example of this in action is the maven.pom.withXml() hook in the > new 'maven-publish' plugin. Bad user code will now be reported like: > > Execution failed for task ':publishMavenPublicationToMavenRepository'. (1) > > Failed to publish publication 'maven' to repository 'maven' (2) > > Failed to notify action. (3) > > Could not apply withXml() to generated POM (4) > > No such property: foo for class: groovy.util.Node (5) > > 1) the TaskExecutionException > 2) the first @contextual exception > 3) the "Failed to notify action" shouldn't really be there. It is > included because ListenerNotifyException is @Contextual, but it > doesn't really provide any failure context. I plan to remove this > annotation. > 4) the UserCodeException message. This is the deepest @Contextual exception > 5) The Groovy exception caught and wrapped by the UserCodeAction > > I hope this makes exception reporting a bit more understandable. > cheers > Daz > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Szczepan Faber Principal engineer@gradleware Lead@mockito --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
