Hi there! I have a problem that I have spent mutli...

# multiplatform

[peekandpoke]

Hi there! I have a problem that I have spent mutliple hours on now, but I could not find a solution.
So we have this situation: We are using a multiplatform library, which is published through bintray.
On my machine everything works fine. On my colleagues machine it does not.

One curious thing is the following. On my machine i can see in IntelliJ that all dependencies are loaded, especially the "commonmp-metadata" ... Please compare the two screenshot I attached.

On my colleagues machine this some does not seem to be fetched properly and therefore things do not compile. He sees lot's of errors of unresolved symbols in the IDE while I do not. Basically non of the packages and classses from the library are recognized.

What is even more strange is that "./gradlew build" does work for him, but "./gradlew assemble" does not. When running assemble the failing gradle task is "compileKotlinMetadata" on the subproject using the multiplatform lib.

We have tried to see what is different in the setups of our systems. Java version 1..8.0_265 is the same. Nodejs 10.19.0 is the same. Npm 6.14.4 is the same.
The only difference we can spot is that I am running Pop!Os and he runs Ubuntu. Another colleague with Ubuntu has the same issue by the way.

Sooooo... long text. Does anyone have an idea what to look for? Thanks a lot.

[mbonnin]

What version of gradle are you using? It might be worth check your ~/.gradle/gradle.properties to see if they're matching

[peekandpoke]

Oh right we use Gradle 6.6.1

[peekandpoke]

./gradlew --version show the exact same output except for the kernel version of Linux

[peekandpoke]

./gradlew --version

------------------------------------------------------------
Gradle 6.6.1
------------------------------------------------------------

Build time:   2020-08-25 16:29:12 UTC
Revision:     f2d1fb54a951d8b11d25748e4711bec8d128d7e3

Kotlin:       1.3.72
Groovy:       2.5.12
Ant:          Apache Ant(TM) version 1.10.8 compiled on May 10 2020
JVM:          1.8.0_265 (Oracle Corporation 25.265-b01)
OS:           Linux 5.4.0-7642-generic amd64

[mbonnin]

I was maybe thinking about gradle metadata support which was only enabled by default with Gradle 6+ but 6.6.1 should work fine

[mbonnin]

It's still worth checking the gradle.properties

[peekandpoke]

In the home directory you mean?

[mbonnin]

Yes

[peekandpoke]

We did... on my machine there is not such file present. On the other one the file is empty.

[mbonnin]

Then it's something else...

[mbonnin]

delete all caches and retry?

[mbonnin]

Or maybe the network configuration makes it so that the artifacts are resolved from different locations?

[peekandpoke]

We did multiple times. Stopped gradle daemons. Disabled incremental build. Nothing.

[peekandpoke]

Ok issue is fixed...
What happened? The mpp library we use is published from my machine and so it landed right away in my .m2 cache.
There also was a problem with the setup of how the lib was published to bintray. Nevertheless using the library kept working on my machine, but not on the machine of my colleagues.

More specific the mistake was the following. In the build.gradle.kts for the library we had this piece of code:

afterEvaluate {

    project.publishing.publications.filterIsInstance<MavenPublication>().forEach {

        it.groupId = group as String

        if (it.name.contains("kotlinMultiplaform")) {
            it.artifactId = project.name
        } else {
            it.artifactId = "${project.name}-${it.name}"
        }
    }
}

The wrong piece here is to rename the kotlinMultiplatform . What we have now is to treat the metadata like this:

afterEvaluate {

    project.publishing.publications.filterIsInstance<MavenPublication>().forEach {

        it.groupId = group as String

        if (it.name.contains("metadata")) {
            it.artifactId = project.name
        } else {
            it.artifactId = "${project.name}-${it.name}"
        }
    }
}

And now finally everything is fine.

[mbonnin]

Aaaaarg, yes mavenLocal() ! Good find!