Publish custom sourcesJar with Android Gradle Kotlin DSL

Since version 5.0, Gradle offers a way to write Gradle scripts in Kotlin.

Gradle Kotlin @ gradle.org

Before Gradle Kotlin support, Groovy was used to write Gradle scripts, and if you are not familiar with Gradle DSL, it is very hard to get into it, as it is not offering good auto-completion.

So what are the benefits to switch from Groovy to Kotlin Gradle DSL:

• Autocompletion
• Instant documentation
• Accessibility to internal sources
• Factorization of your Gradle configurations

Here, is the official communication from Gradle about Kotlin DSL.

We will use buildSrc to export the publishing part, this is not mandatory, but this is really helpful when you are working with multiple modules that you have to publish, there are already some nice articles around it.

Better Dependency Management Using buildSrc + Kotlin DSL

Why use a sourceJar task while publishing?

For example in our Teads codebase, the IDE is automatically downloading the sources as follows:

Before, code is compiled

After, some documentation was added, the code is more readable

If you want to expose your sources when you have exposed APIs that are documented or well explained by themselves, this will allow:

• Provide a better understanding of your public APIs
• Know which arguments will be passed through your functions
• The possibility to add a good description of your code

At Teads, we are building a native SDK for Android & iOS, and we wanted to share the public sources that our customers use without providing the whole source code.
At first, it was not easy to find how to do it using Groovy because we are not huge Gradle users. We finally found it after a while, here is how to do it:

1 — Configure a simple publishing extension

The configuration is exported into a true Kotlin file that will be used across the project by multiple modules, but you can do the same within one simple Gradle file.

In the following example, we will create an extension function of Project, and this will allow us to call directly this function inside our modules.

Since we want to publish, we need to apply the plugin maven-publish, it will be automatically applied to the module that calls the publishing function.
We use the extension function, gently brought by the Kotlin DSL, configure<LibraryExtension>("android") from extensions to configure the current android module. Here we want to configure the publishing part.

Note: A boolean is used to enable/disable publish with sources, not mandatory.

2 — Configure the sourceJar task

First, we need to know the name of our build variant, since we are using default here, it will be sourceReleaseJar.
But, if you are using some custom build variant, for example, you are handing freemium/premium on your app, then, it will be sourceFreemiumReleaseJar , sourcePremiumReleaseJar.

We need to use the afterEvaluate delegate, because the task is not directly created, it will be created after the evaluation as the function name suggests.
Here, we are trying to look for a task with the type Jar that is called sourceReleaseJar.

Once inside the configuration bracket of our Jar task, we can now include the specific classes that we want to expose by using include("path/to/your/class").

3— Call it from your selected module

Now that everything is setup, you can call this new extension method inside your module build.gradle.kts

The function needs to be called outside the android bracket because it will use the Gradle Project extension to set up the android publishing.

Note: The imported package name come from the buildSrc package where the file is created

Summary

Gradle is getting easier with the use of Kotlin DSL, from my own experience, I'm not very aware of the Gradle API, and still achieve to do some nice things because the Kotlin API eases the development and the auto-completion helps a lot. Tweaking the publishing/publications function is quite a blind spot when you are using Groovy as it has no completion, you have to keep dealing with the official documentation on the website.

Now we are able to add some documentation to our public codebase without leaking our private code.