<@U0BLPSJAK> hello, I'm interested in the kmp grad...

# korlibs

[Davide Giuseppe Farella]

@Deactivated User hello, I'm interested in the kmp gradle plugin, but there is not doc. Could you guide me though? I always had trouble with publishing to bintray and I think I'd get crazy with kmp 😅

[Deactivated User]

Do you mean the easy-plugin or the korge-plugin? Do you want to use it or just to figure out how to do publishing?

[Davide Giuseppe Farella]

I’m talking about the easy one. Let’s say that I’m trying to solve a publishing problem in one of my projects, but if the plugin is cool, I could get use of it.

[Davide Giuseppe Farella]

( Just in case, that’s the problem I face: https://kotlinlang.slack.com/archives/C19FD9681/p1591457385464400 And I came to find a solution in you repo, because I know you have quite a few libs 🙂 )

[Deactivated User]

Not sure if coupled somehow to korlibs. I hope it is not the case, but can't guarantee since nobody else tried to use it as far as I'm concerned.
In the end you just have to apply it, then add a few properties to the gradle.properties file, like this:

# bintray location
<http://project.bintray.org|project.bintray.org>=korlibs
project.bintray.repository=korlibs
project.bintray.package=korio

# project info
project.name=korio-root
project.scm.url=<https://github.com/korlibs/korio>
project.description=I/O utilities for Kotlin
project.license.name=MIT License
project.license.url=<https://raw.githubusercontent.com/korlibs/korio/master/LICENSE>

[Davide Giuseppe Farella]

Yes, I found that.
Let’s say that I have a small lib for publishing, but I’m struggling with an edge case, so coming to your repos I noticed that and I was wondering if that could really help me to clean up gradle’s config for KMP projects, but I was really struggling to understand its purpose, beside the mere publishing 🙂

[Deactivated User]

Aha

[Deactivated User]

Almost each new version of Kotlin changed a few things in the gradle plugin and wanted to abstract that so I could update just in one place with something as stable as possible via convention. Initially it didn't offer for example JS testing. Also initially we were not able to use the gradle metadata modules and wanted to avoid adding an implementation line for each dependency and platform. It handles publishing via CI. And adds a createNewVersion task that bumps the version= in the gradle.properties + create a one commit with that and another commit with -SNAPSHOT. It also adds a http server for JS (not sure if that's available already on Kotlin.JS). It also adds automatically some repositories (like the bintray ones) etc. It detects and applies Android, allowing to set sdk versions via properties. It configures JVM testing to show exceptions andallow to configure them in headless mode so you can use some AWT functionality on CI directly. Also configure all the native targets + common variants

[Davide Giuseppe Farella]

Oh, I see, thank you 🙂
I seen exposeVersion() into your libs, is that somehow related with the publishing?
In my lib publish must be called explicitly in the module’s gradle, so I can inject params in DSL style, like

publish {
  // explicit params or fetch from gradle.properties
  ...
  developers {
    dev {
      name = "4face"
      mail = "..."
  }
  ..
}

Would that somehow be possible with your lib, where publish is implicit?

Does it support nested modules, like following?

- root
  - util
    - kotlin
    - android
  - something
    - somethingOther
...

[Deactivated User]

exposeVersion creates a .kt file with a constant with the library version updated with build.gradle.kts . That's optional

[Davide Giuseppe Farella]

I see, thank you 🙂

[Deactivated User]

Regarding to structure: As far as I remember you can have submodules (in fact all the libraries have one level of submodules). You can just omit the targets you don't need (I think)

[Davide Giuseppe Farella]

Sadly it seems to be tied to you machine 🙂

A problem occurred starting process 'command '/Users/davide/Dev/Kotlin/Assert4K/gradlew_win''