Home » Java » Additional gradle configuration breaking compilation when using flatDir repo

Additional gradle configuration breaking compilation when using flatDir repo

Posted by: admin October 26, 2017 Leave a comment

Questions:

I’m using the approach from Gradle – extract file from depended jar to extact a .so file from inside a native JAR.

configurations {
    special
}

dependencies {
    special('org.jogamp.jogl:jogl-all:2.3.2:natives-linux-i586')
}

task extract(type: Copy) {
    from({ zipTree(configurations.special.singleFile) })
    include 'natives/linux-i586/*.so'
    into "$buildDir/extracted"
}

This works fine, however it appears to break compilation of code that depends on org.jogamp.jogl:jogl-all:2.3.2, the non-native Java part.

TestJogl.java:1: error: package com.jogamp.opengl does not exist
import com.jogamp.opengl.GL;

The compilation fails if the project is built with clean extract build but not clean build

I’ve simplified the code to

import com.jogamp.opengl.GL;

public class TestJogl {
    private GL gl;
}

and corresponding build.gradle

apply plugin: "java"

dependencies {
    compile "org.jogamp.jogl:jogl-all:2.3.2"
}

I’ve isolated this issue to the usage of “flatDir” repo. The exact same project compiles fine when using mavenCentral(). Note using a legacy corporate network without artifactory or direct Internet access.

allprojects {
    repositories {
        flatDir {
           dirs "$rootProject.projectDir/local-repo"
           // contains jogl-all-2.3.2-natives-linux-i586.jar
           //          jogl-all-2.3.2.jar
        }
    }
}

I’ve managed to work around the issue by changing the dependency to explicity specify @jar, which should be implicit

compile "org.jogamp.jogl:jogl-all:[email protected]"

The same problem occurs in both single and multi project layouts.

My analysis: This is a bug in Gradle. Somehow when using flatDir Gradle gets confused and thinks that the dependency has been setup, but uses the native JAR instead of the Java JAR.

Questions: Am I doing something wrong? Is this a bug? Is there another way to workaround it?

Environment: Gradle 3.5, JDK 1.8u144

Answers: