Hello, I was reviewing the readme [1] and wondered...

# coroutines

[Scott Rankin]

Hello, I was reviewing the readme [1] and wondered how I add your maven central repository? I see instructions for gradle but we're using mvn. Is there an example somewhere? I searched through this channel and the github and couldn't find an example.

[1] https://github.com/Kotlin/kotlinx.coroutines#readme

[ephemient]

I believe the default repository layout in mvn should already include maven central

[ephemient]

however, because Maven doesn't know how to resolve the Kotlin Multiplatform variants, you'll have to do that yourself, e.g.

<dependency>
  <groupId>org.jetbrains.kotlinx</groupId>
  <artifactId>kotlinx-coroutines-core-jvm</artifactId>
  <version>1.7.1</version>
</dependency>

[ephemient]

oh actually it looks like the POM is customized to have that transitive dependency (only matters for Maven, since Gradle interprets the module metadata just fine) so that shouldn't be necessary for kotlinx.coroutines (may still be necessary for other Kotlin multiplatform libraries though)

[Scott Rankin]

Hm. Mine on Windows seems to default to only using <https://repo.maven.apache.org/maven2> which seems to complain about not being able to find a number of the org.jetbrains jars. Specifically org.jetbrains.kotlinxkotlinx coroutines bomjar:1.6.2,

0:04:12.126 [ERROR] Failed to execute goal on project engine-settings: Could not resolve dependencies for project pragma:engine-settings:pom:PRAGMA-LOCAL-SNAPSHOT: Could not find artifact org.jetbrains.kotlinx:kotlinx-coroutines-bom:jar:1.6.2 in central (<https://repo.maven.apache.org/maven2>)

Here's a snippet of our engine-settings.xml which contains,

<kotlin-coroutine.version>1.6.2</kotlin-coroutine.version>

        <dependency>
            <groupId>org.jetbrains.kotlinx</groupId>
            <artifactId>kotlinx-coroutines-jdk8</artifactId>
            <version>${kotlin-coroutine.version}</version>
        </dependency>
        <dependency>
            <groupId>org.jetbrains.kotlinx</groupId>
            <artifactId>kotlinx-coroutines-core</artifactId>
            <version>${kotlin-coroutine.version}</version>
        </dependency>
        <dependency>
            <groupId>org.jetbrains.kotlinx</groupId>
            <artifactId>kotlinx-coroutines-debug</artifactId>
            <version>${kotlin-coroutine.version}</version>
        </dependency>

        <!-- TEST DEP BELOW -->
        <dependency>
            <groupId>org.jetbrains.kotlinx</groupId>
            <artifactId>kotlinx-coroutines-test</artifactId>
            <version>${kotlin-coroutine.version}</version>
            <scope>test</scope>
        </dependency>

If I use help to generate the effective pom I see the following repositories and pluginRepositories neither of which contains repo1.maven.org/maven2,

<repositories>
      <repository>
        <snapshots>
          <enabled>false</enabled>
        </snapshots>
        <id>central</id>
        <name>Central Repository</name>
        <url><https://repo.maven.apache.org/maven2></url>
      </repository>
    </repositories>
    <pluginRepositories>
      <pluginRepository>
        <releases>
          <updatePolicy>never</updatePolicy>
        </releases>
        <snapshots>
          <enabled>false</enabled>
        </snapshots>
        <id>central</id>
        <name>Central Repository</name>
        <url><https://repo.maven.apache.org/maven2></url>
      </pluginRepository>
    </pluginRepositories>

[ephemient]

BOM doesn't need a JAR, it's a .pom-only artifact. Maven is supposed to handle that just fine

[ephemient]

that URL is one of the canonical URLs for Maven Central

[Scott Rankin]

So this is more of a maven issue or transitive dependency or something?

[Scott Rankin]

I had assumed that it was something different between repo.maven.apache.org/maven2 and repo2.maven.org/maven2 but probably a bad assumption

[Scott Rankin]

I'm by no means confident in my maven skills but looking at the output of mvn -X dependency:tree it looks like the dependency to the kotlinx-coroutines-bom comes from kotlinx-coroutines-debug?

10:46:01.835 [DEBUG]    org.jetbrains.kotlinx:kotlinx-coroutines-debug:jar:1.6.2:compile
10:46:01.835 [DEBUG]       org.jetbrains.kotlinx:kotlinx-coroutines-bom:jar:1.6.2:runtime
10:46:01.835 [DEBUG]       net.java.dev.jna:jna:jar:5.9.0:runtime
10:46:01.835 [DEBUG]       net.java.dev.jna:jna-platform:jar:5.9.0:runtime

However, it also looks like the mockk-jvm (and mockk-dsl-jvm) we are using might depend on kotlinx-coroutines-bom 1.6.4 [1] which perhaps is causing maven some trouble?

10:46:01.196 [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for <https://repo.maven.apache.org/maven2>
10:46:01.211 [DEBUG] Writing tracking file C:\Users\Scott\.m2\repository\io\mockk\mockk-jvm\1.13.3\_remote.repositories
10:46:01.211 [DEBUG] Writing tracking file C:\Users\Scott\.m2\repository\io\mockk\mockk-jvm\1.13.3\mockk-jvm-1.13.3.pom.lastUpdated
10:46:01.214 [DEBUG] Using transporter WagonTransporter with priority -1.0 for <https://repo.maven.apache.org/maven2>
10:46:01.214 [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for <https://repo.maven.apache.org/maven2>
10:46:01.227 [DEBUG] Writing tracking file C:\Users\Scott\.m2\repository\org\jetbrains\kotlinx\kotlinx-coroutines-bom\1.6.4\_remote.repositories
10:46:01.227 [DEBUG] Writing tracking file C:\Users\Scott\.m2\repository\org\jetbrains\kotlinx\kotlinx-coroutines-bom\1.6.4\kotlinx-coroutines-bom-1.6.4.pom.lastUpdated

[1] https://repo1.maven.org/maven2/io/mockk/mockk-jvm/1.13.3/mockk-jvm-1.13.3.pom

[Scott Rankin]

Switching mine to 1.6.4 makes things go without error so not sure. I was trying to stay on 1.6.2 since that's what the ktor 2.0.3 depended on but ultimately we're trying to make our way to ktor 2.3.x so will have to come back to this another time.

[ephemient]

when multiple dependencies depend on different versions of the same artifact, Maven chooses the first version it sees

[Scott Rankin]

Thanks again for your assistance!

[ephemient]

which is terrible behavior compared to Gradle (or any other reasonable build system) which picks the highest version by default

[ephemient]

most libraries (including kotlinx.coroutines) are ABI-compatible for upgrades (assuming only the stable public API is used)

[Scott Rankin]

yeah, every time I have to dig into some maven thing (which is long enough periods where I forget everything from the last venture into uncharted territory) I discover some behavior that seems really curious and not the way I would have thought.