https://kotlinlang.org
Join Slack
What's the best way to generate an .aar file from a multiplatform build.gradle file? My iOS targets ...
# multiplatform
s
What's the best way to generate an .aar file from a multiplatform build.gradle file? My iOS targets generate .framework outputs, but I would now like to wrap my android target jar file in an .aar file. Thanks in advance.
k
change your jvm target to and android target
s
Thanks for that Kris! I will read all the 4 parts as I might need to do a fat framework for iOS as well.
@Kris Wong Ok, so I tried this (switching from jvm to android target), but it seems that I lost my android source sets along the way. I will investigate. Keep in mind that I have only one global build.gradle for now, so it englobes all the multiplatform and platform-specific stuff. (I know, far from ideal, I'll refactor it into multiple build.gradle files eventually, but I don't have time right now.)
k
not sure what you mean. source code doesn't just disappear.
s
The folders are still there, but it looks like gradle doesn't recognize the android sourcesets:
k
that's normal
s
Ok, I wasn't expecting that. ā€¢ When I refactored the modules (jvmMain/Test to androidMain/Test) in the Project Pane, it prompted me if I wanted to update the Module or Directory. I tried Module, but it wouldn't let me, saying it couldn't rename a root module (?). So I had to choose Directory. ā€¢ EDIT: Also, when I look at the .aar filed generated, it contains com.example.android.BuildConfig.class. Where does that come from?
k
the android gradle plugin. All android artifacts have a BuildConfig
s
I see. The com.example.android namespace comes from what is in the Android manifest file, right?
Copy code
<?xml version="1.0" encoding="utf-8"?>
<manifest package="com.example.android" />
So I should probably replace com.example.android by com.mycompany.myproject I guess?
k
yes
s
So by default, it looks like the aar files don't contain the Kotlin dependencies (especially the Kotlin version used). Does either of the plugins allow adding such dependencies? Initially I was thinking "pom file", but maybe it isn't the "standard" way to include this in an aar file?
k
that's what maven is for. otherwise you'll have to build a "fat" aar.
s
Ok, I'll try building a "fat" aar. Part 5 of your series maybe? šŸ˜‰
k
i have no idea how to do that šŸ™‚
you're going to have to dig around the android plugin source using IDEA
s
Yep. But honestly in my case, since I don't use Android APIs, a "skinny" aar file doesn't buy me much compared to a .jar file if it won't include the Kotlin runtime library or at least the version of Kotlin used. I was planning of using an aar file to include such dependencies, since we don't plan on publishing on Maven.
k
are you using Android APIs or not?
s
No. But our client/beta tester/partner on the Android side had suggested that one option to include the dependencies (Kotlin version) was through an aar file. Now these dependencies may be as a pom file or not, this isn't clear to me yet.
k
just ship a fat jar using the shadow jar plugin
there's a small amount of manual configuration to get it to work with KMP
s
If I go that route (fat jar), do you suggest then me to revert to a jvm target? Or should I keep the android target? Or it doesn't really matter?
k
an android target is incompatible with a jar output
šŸ‘ 1
s
So it boils down to what it simpler to achieve between a fat aar and a fat jar, basically.
k
yes and no. i wouldn't create an android target unless you need Android SDK APIs
otherwise you're limiting your audience, and bringing in that whole toolchain for no reason
s
Fair enough. But there's still a non-zero probability (let's say 25%) that in the mid-future, we need to add some BLE layers, which would require Android SDK APIs. On the other hand, maybe it's a "we'll cross that bridge at that moment" situation since the conversion isn't really complicated.
@Kris Wong I'm reconsidering using a fat jar. Our beta tester isn't to keen about that, thinking that will lead to conflicts and forcing/freezing a fixed version of Kotlin. It looks like the Shadow plugin can handle "Library Bundling" to prevent such issues to a certain extent, but I'm not sure how far it can go. Sigh, only one way to know...
k
this is why we have artifact repos/dependency management
s
Yes, but that means publishing to a maven or jcenter repo.
I thought producing an AAR file was an alternative to having to publish on a repo (a la Maven).
k
what do you think gets published šŸ˜›
s
I know that publishing is the preferred/modern way to go, but for some reasons (beyond my control), we simply generate the artifacts on our DevOps and then copied/hosted on our developer website. That's why I was looking to package my SDK, including dependencies, in a practical and standard format. I thought a "standard" aar file was the solution, but apparently not, since it needs to be a "fat" aar. I'll get to Rome eventually. šŸ™ƒ
1140 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by