Gradle plugin build pulls in wrong version of commons-io

[David_Moles]

What appears to be happening is that ‘compileJava’ pulls in ‘commons-io-1.4.jar’ from the gradle distribution, in preference to my declared ‘commons-io:commons-io:2.4’. When I try to call a method (‘readLines(InputStream, Charset)’) introduced in a later version, Gradle can’t find it:

$ gradle compileJava

:compileJava

/home/dmoles/Projects/m12n-plugins/tools/m12n/multiproject-plugin/src/main/java/m12n/tools/multiproject/dependencies/DependencyExtractor.java:42: error: no suitable method found for readLines(ByteArrayInputStream,Charset)

List lines = IOUtils.readLines(new ByteArrayInputStream(stream.toByteArray()), Charsets.UTF_8);

^

method IOUtils.readLines(Reader) is not applicable

(actual and formal argument lists differ in length)

method IOUtils.readLines(InputStream,String) is not applicable

(actual argument Charset cannot be converted to String by method invocation conversion)

method IOUtils.readLines(InputStream) is not applicable

(actual and formal argument lists differ in length)

1 error

:compileJava FAILED

FAILURE: Build failed with an exception.

The ‘dependencies’ section of my ‘build.gradle’ (abbreviated):

dependencies {

compile ‘commons-io:commons-io:2.4’

compile gradleApi()

compile localGroovy()

}

‘gradle dependencies’ shows the right thing:

±-- commons-io:commons-io:2.4

Obviously in this specific case I can work around it by calling the older method, but is there a general fix for this? I don’t want to have to individually track down every time I happen to use a library that’s also used by Gradle itself.

[luke_daley]

There’s no general fix available. The work we are doing around plugin use (plugin portal) and plugin development is working towards a solution here, but we are not there yet.

To make this work we have to get into non trivial classloading, which is not a problem at plugin use time, but becomes very awkward at plugin build and test time. As such, it’s a non trivial fix. We’ll get there though.

In the shorter term, what we will do is provide a warning/report that you can use to find out when your dependencies clash with Gradle’s, which implies your going to have a hard time testing with the way things are.

[ChrisNevill]

This seems to have made it’s way into Android Studio

[carlo_lf (Carlo Luib-Finetti)]

Arghh! Maybe I’m faced with the same problem? (using Gradle 2.1 and 2.2)

I recently converted our classes from using Log4j to SLF4J; because now there are explicit different import statements regarding Logger and LoggerFactory-classes, it seems to be clear, what the compiler should see. Within Eclipse (where I do not use Gradle), everything works fine.

But when doing a Gradle build on cmd line, I get strange (‘beautiful’) compiler errors like these:

Q:\sources\branches\DEV\trunkSLF4J\com.tsystems.favbg.ui.core\src\main\java\com\tsystems\favbg\ui\core\action\AblegenUbe
rnehmenActionDelegate.java:38: error: method getLogger in class LoggerFactory cannot be applied to given types;
   private static final Logger LOGGER = LoggerFactory.getLogger(AblegenUbernehmenActionDelegate.class);
                                                     ^
  required: String
  found: Class<AblegenUbernehmenActionDelegate>
  reason: actual argument Class<AblegenUbernehmenActionDelegate> cannot be converted to String by method invocation conv
ersion
Q:\sources\branches\DEV\trunkSLF4J\com.tsystems.favbg.ui.core\src\main\java\com\tsystems\favbg\ui\core\action\AblegenUbe
rnehmenActionDelegate.java:70: error: cannot access StdErrLog
      LOGGER.info("Erstelle neue Akte mit GZ " + geschaeftszeichen
            ^
  class file for org.mortbay.log.StdErrLog not found
Q:\sources\branches\DEV\trunkSLF4J\com.tsystems.favbg.ui.core\src\main\java\com\tsystems\favbg\ui\core\view\AbstractBase
ViewPart.java:41: error: method getLogger in class LoggerFactory cannot be applied to given types;
   protected final Logger LOGGER = LoggerFactory.getLogger (this.getClass());
                                                ^
  required: String
  found: Class<CAP#1>
  reason: actual argument Class<CAP#1> cannot be converted to String by method invocation conversion
  where CAP#1 is a fresh type-variable:
    CAP#1 extends AbstractBaseViewPart from capture of ? extends AbstractBaseViewPart
Q:\sources\branches\DEV\trunkSLF4J\com.tsystems.favbg.ui.core\src\main\java\com\tsystems\favbg\ui\core\view\AbstractBase
ViewPart.java:264: error: cannot find symbol
      LOGGER.trace("Benutzer hat Button " + retval + " gedr├╝ckt.");
            ^
  symbol:
 method trace(String)
  location: variable LOGGER of type Logger
Q:\sources\branches\DEV\trunkSLF4J\com.tsystems.favbg.ui.core\src\main\java\com\tsystems\favbg\ui\core\service\Perspecti
vePreferenceService.java:24: error: method getLogger in class LoggerFactory cannot be applied to given types;
   public static final Logger LOGGER = LoggerFactory.getLogger (PerspectivePreferenceService.class);
                                                    ^
  required: String
  found: Class<PerspectivePreferenceService>
  reason: actual argument Class<PerspectivePreferenceService> cannot be converted to String by method invocation convers
ion
Q:\sources\branches\DEV\trunkSLF4J\com.tsystems.favbg.ui.core\src\main\java\com\tsystems\favbg\ui\core\service\Perspecti
vePreferenceService.java:64: error: cannot find symbol
            if (LOGGER.isDebugEnabled()) {
                      ^
  symbol:
 method isDebugEnabled()
  location: variable LOGGER of type Logger
Q:\sources\branches\DEV\trunkSLF4J\com.tsystems.favbg.ui.core\src\main\java\com\tsystems\favbg\ui\core\service\Perspecti
vePreferenceService.java:65: error: no suitable method found for debug(String)
               LOGGER.debug("Lese Memento " + memento.getType()
                     ^
    method Logger.debug(String,Throwable) is not applicable
      (actual and formal argument lists differ in length)
    method Logger.debug(String,Object,Object) is not applicable
      (actual and formal argument lists differ in length)

Note, this happens only in one project (so far); projects, on which this project depends on, compile fine. Also note, as for the Logging-API, I declared this dependency on SLF4J globally for all projects in the master build.gradle.

Any ideas what I can do?