question about kotlin-dsl, seems like it behaves differently than groovy: ```subprojects { reposi...

# gradle

[robstoll]

question about kotlin-dsl, seems like it behaves differently than groovy:

subprojects {
   repositories {
        mavenCentral()
        jcenter()
    }
}

Dependency is only available in jcenter but the build fails telling me that the dependency is not available in mavenCentral. How can I declare two repositories?
(https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:declaring_multiple_repositories looks like it should be correct)

[Javier]

it is correct, are you sure it is a subproject?

[Vampire]

Groovy and Kotlin do not behave differently, they are just different APIs for the same underlying classes. What is the full error message you get?

[robstoll]

good, that's what I figured as well, that it should behave exactly like grooy. Must have been a glitch yesterday. No idea why though, but fact is, I wanted to copy the error today but I cannot reproduce the error any more, now it always searches in jcenter as well and even more strange, I realised I have also other dependencies which are resolved first and are only available in jcenter and gradle did not complain about those 🤷‍♂️

[robstoll]

oho... its back again:

> Could not resolve all files for configuration ':0.14.0-api-fluent-en_GB:conf_0.14.0_api-fluent-en_GB_js'.
   > Could not find atrium-api-fluent-en_GB-js-0.14.0-testsources.jar (ch.tutteli.atrium:atrium-api-fluent-en_GB-js:0.14.0).
     Searched in the following locations:
         <https://repo.maven.apache.org/maven2/ch/tutteli/atrium/atrium-api-fluent-en_GB-js/0.14.0/atrium-api-fluent-en_GB-js-0.14.0-testsources.jar>

[robstoll]

I should mention, the problem seems to occur for an own configuration which I define like the following:

configurations { create(dynamicName) }

What I have defined for repositories should be applied for all configurations, right?

[robstoll]

yes, this is correct and I just found a workaround... if I define jcenter before mavenCentral, then it works 🤷‍♂️

[Vampire]

Hm, but that shouldn't be the case. 😕

[Vampire]

And I personally would not do it.
JCenter is very unreliable.
Afair JCenter also forwards to Maven Central for things it does not have, so it would also make things slower and resolve things only from JCenter if it is not down.

[robstoll]

I would also prefer to have mavenCentral first but with the current buggy behaviour of gradle... I don't know why it stops after searching in mavenCentral

[Vampire]

It would be good if you could reliably reproduce and report it, otherwise it is hard to become fixed ever. 🙂

[Vampire]

I've never seen such a behavior

[Vampire]

Ah, look at https://repo.maven.apache.org/maven2/ch/tutteli/atrium/atrium-api-fluent-en_GB-js/0.14.0/

[Vampire]

The version is actually there

[Vampire]

Just the testsources artifact is missing

[Vampire]

So the version was found on Maven Central and it just misses the artifact

[Vampire]

You could configure that the whole dependency is not searched on MavenCentral but only on JCenter

[robstoll]

OK, now I know at least what problem I encounter:
https://github.com/gradle/gradle/issues/3666

[robstoll]

the pom file exists in mavenCentral but one specific jar does not

[Vampire]

Yes, I just said this, didn't I? 🙂

[Vampire]

And I also mentioned how to solve it in case you missed it 😉

[robstoll]

Yes I missed it, was just searching myself and came to the same conclusion. Should have waited a bit longer 😄

[Vampire]

This is what you are after: https://docs.gradle.org/current/userguide/userguide_single.html#sec:repository-content-filtering

[robstoll]

thanks

[Vampire]

It basically is the "when some repositories contain corrupted metadata or artifacts" use-case, as Maven Central does not contain all artifacts

[Vampire]

You might also report to that project to get their release process fixed

[robstoll]

Already happened, its my own project 😉

[Vampire]

Ah, ok, great 🙂