I'm really confused by how to share code I write i...

# announcements

[Daniel]

I'm really confused by how to share code I write in kotlin with the world. The only guides I can find for publishing kotlin libraries are for multiplatform. It seems like I need to pick a repository and have totally different gradle code for each. Is there some way to do this that doesn't take hours?

[ephemient]

if you're writing JVM or Android (not multiplatform) code, publishing a Kotlin library is exactly the same as publishing a Java or Android library, nothing Kotlin-specific about it.

[Daniel]

Thanks. I guess I'll try and figure out how to do that then

[ephemient]

publishing from Gradle to a Maven repository you have access to is easy. the most challenging part may be verifying ownership and key management, if you want to publish to Maven Central

[Daniel]

Thanks. This is a bit of a dumb question, but how do I make a new library project? Using either IntelliJ, android studio, or the command line? I've tried the "new module" option, but that works in the current project

[ephemient]

if that's what you want to do, https://github.com/gradle-nexus/publish-plugin/

[ephemient]

eh, I just create build.gradle.kts/settings.gradle.kts from scratch, no need for IDE (although it can do that as well)

[Daniel]

I'd like to be able to do that. How would you learn that? I haven't found the gradle docs very easy to understand. I get caught up in the minutia and don't get how it goes together

[ephemient]

yeah Gradle is somewhat difficult to understand in pieces… you need a pretty full model of the whole thing

[Daniel]

I've found talks on youtube about gradle in general, and about kts specifically. I found it a bit difficult to translate everything from groovy. Do you know of anything that exists that explains the full model with kts?

[ephemient]

kotlin dsl vs groovy dsl doesn't change anything about the Gradle model, it just sets up type-safe accessors

[Daniel]

Yeah, but I don't understand the gradle dsl syntax and I'd ideally prefer not to learn the whole thing just to understand how to implement it in kts

[Daniel]

Thanks for all the help though. You've given me enough to get started, I think. I'll stop bothering you now 🙂

[ephemient]

no problem

[Kirill Grouchnikov]

One lightweight option is to copy-paste the structure of an existing project (something simple with a couple of modules and nothing custom in its build script), remove all its sources and use that as your "template". It doesn't mean that they did it "right". But that's just a starting point for you.

[Daniel]

Interesting, thanks

[ephemient]

I'm sure you can find better examples out there, but I have a couple of tiny projects that you could copy from:
- https://github.com/ephemient/builder-generator is set up so that JitPack.io can build and distribute artifacts
- https://github.com/ephemient/moshi-contrib is set up to build and publish to GitHub Packages

[Kirill Grouchnikov]

Unless you want to spend time shaving the yak and going deep into learning everything around the core of your project. Which a lot of people love to do

[Daniel]

I've never written in a language where this was something you could go deep into. In general I like doing that, but I don't really see why it should be worth it

[Kirill Grouchnikov]

It's not the language. It's the tooling infrastructure - building, testing, continuous integration, deployment, lint rules, etc.

[Daniel]

Fair enough. I think of all that when comparing languages, just like I consider the great IDE support a plus of kotlin. I know some people disagree with that though

[Tyler Hodgkins]

I'd agree with you - build tooling is a huge part of what makes a language/platform. Gradle does take some time to learn but the benefit is that it is very well established and provides lots of capabilities. As with many things, capability/power comes with a tradeoff - in this case it's the learning curve.

But as others have said, I think the best place to start is to find a simple project with a Gradle build that publishes somewhere.

Either publish a "Release" (usually for end-user artifacts, like UI/CLI apps or plugins) or to GitHub Packages, which is an artifact repository useful for storing things designed as dependencies, like libraries, etc.

I just found this doc, which seems like a good intro on using GitHub Packages with Gradle :)

https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-gradle-registry#installing-a-package

If you want to go a step further and automate your builds (testing for PRs and publishing for merges) you could also check out TravisCI as your CI tool, it's free for open source repositories.

[Tyler Hodgkins]

I'd recommend getting used to the basics (configuring a project to build & run tests) before delving into publishing/CI though.

[Tyler Hodgkins]

One nice thing about Kotlin is that there is essentially one accepted build tool - Gradle. There are alternatives and they have promising features, but a huge amount of community support & documentation goes into working with Gradle so you should be able to find out almost anything you need.

I'd also strongly recommend using the Kotlin DSL for Gradle - it's different than Groovy but
1) you'll learn Kotlin faster
2) The build scripts will be easier to understand in the end because they're the same language as the project
3) As far as I know, Groovy for Gradle is deprecated or at the very least no longer the main focus of their team.

[ephemient]

I do not recommend Travis CI at this point: after https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing it's been nearly impossible to use

[ephemient]

just use GitHub Actions or GitLab CICD or sourcehut or whatever

[napperley]

Do note that GitHub packages aren't accessible by people who don't own the packages. With repositories on GitLab access isn't an issue.

[napperley]

Most of the publishing stuff in Kotlin is the same as Java except for the part with generating reference documentation, especially when working on a Kotlin Native or Kotlin JS project. When Kotlin WASM arrives the reference documentation process will be the same as Kotlin Native, and Kotlin JS.

[Tyler Hodgkins]

You can publish packages in a public repository (public packages) to share with all of GitHub, or in a private repository (private packages) to share with collaborators or an organization.

https://docs.github.com/en/packages/learn-github-packages/introduction-to-github-packages

[ephemient]

GitHub packages can be accessible to all GitHub users, but the Maven repository require authentication for all access (even just read access)
hopefully they change this at some point - they've already fixed their Docker repository

[Tyler Hodgkins]

I see, that's an interesting point.