[GRADLE-1384] Desire ability to have better control of logging, especially for Ivy Created: 09/Feb/11  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Improvement
Reporter: Spencer Allain Assignee: Unassigned
Resolution: Won't Fix Votes: 2


There are cases, especially when trying to support optional plugins, where the dependency resolver is Ivy, yet the dependencies cannot be found on some system configurations.

All current public logging apis within Gradle do not allow adjusting Ivy's output. The default Ivy behavior is to spit out a considerable amount of warning messages that really should not be seen by the user.

Comment by Spencer Allain [ 09/Feb/11 ]

I have something working now that stops Ivy from cluttering up the output (but doesn't disable it forever), but calling it a hack would be too kind. Below are the relevant snippets:

// Outside of any tasks
import org.slf4j.LoggerFactory
import ch.qos.logback.classic.Logger

// Inside task setup that wants to check dependencies and do something intelligent
task myTask {
  def ch.qos.logback.classic.Logger ivyLogbackLogger

  try  {
    // HACK: Turn off Ivy messages!!!!!!
    ivyLogger = 'org.gradle.api.internal.artifacts.ivyservice.IvyLoggingAdaper'
    ivySlf4jLogger = LoggerFactory.getLogger(ivyLogger)

    ivyLogbackLogger = (ch.qos.logback.classic.Logger)ivySlf4jLogger

    // ... something that actually tries to resolve via Ivy .resolve(), .asPath(), etc.
  } catch (ResolveException re) {
    // Adjust logic -- I'm actually setting a property for a later onlyIf {} check
  } finally {
Comment by Hans Dockter [ 10/Feb/11 ]

Hi Allain,

do you mean the infamous 'error' message if you resolve the same dependency with a different resolver?

Comment by Spencer Allain [ 10/Feb/11 ]

No. I mean the normal warning messages when Ivy cannot resolve a dependency. I have some 3rd party tools that are not accessible on every network where builds will occur.

When they are not found, Ivy spits out the normal very verbose warning messages that I do not want the user to see. I just want to notify the user that the absent 3rd party tool is not accessible (likely never will be on such a network) and the task(s) normally associated with it will be skipped if attempted to be invoked.

I'm essentially writing a custom plugin and using Ivy to resolve the dependencies for the tools and need to be able to test whether dependencies resolve properly without spitting out Ivy-generated warning/error messages to the end user.

Comment by Peter Niederwieser [ 10/Feb/11 ]

I often wish I had a way to turn down/off Ivy logging. The amount of Ivy logging (e.g. on info level) is ridiculous and makes it hard to find other useful information.

Comment by Eric Deandrea [ 27/Aug/13 ]

I have a similar case (not related to ivy) where I am using a 3rd party library and it is throwing a whole bunch of stuff out to the gradle console that I don't want or care to see. I would like to see a way where, given some class, I could adjust the log level for that class (like in a logback config file).

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:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

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.

Generated at Wed Jun 30 11:54:11 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.