s

    Sylvain Patenaude

    2 years ago
    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.
    Kris Wong

    Kris Wong

    2 years ago
    change your jvm target to and android target
    s

    Sylvain Patenaude

    2 years ago
    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.)
    Kris Wong

    Kris Wong

    2 years ago
    not sure what you mean. source code doesn't just disappear.
    s

    Sylvain Patenaude

    2 years ago
    The folders are still there, but it looks like gradle doesn't recognize the android sourcesets:
    Kris Wong

    Kris Wong

    2 years ago
    that's normal
    s

    Sylvain Patenaude

    2 years ago
    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?
    Kris Wong

    Kris Wong

    2 years ago
    the android gradle plugin. All android artifacts have a BuildConfig
    s

    Sylvain Patenaude

    2 years ago
    I see. The com.example.android namespace comes from what is in the Android manifest file, right?
    <?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?
    Kris Wong

    Kris Wong

    2 years ago
    yes
    s

    Sylvain Patenaude

    2 years ago
    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?
    Kris Wong

    Kris Wong

    2 years ago
    that's what maven is for. otherwise you'll have to build a "fat" aar.
    s

    Sylvain Patenaude

    2 years ago
    Ok, I'll try building a "fat" aar. Part 5 of your series maybe? 😉
    Kris Wong

    Kris Wong

    2 years ago
    i have no idea how to do that 🙂
    you're going to have to dig around the android plugin source using IDEA
    s

    Sylvain Patenaude

    2 years ago
    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.
    Kris Wong

    Kris Wong

    2 years ago
    are you using Android APIs or not?
    s

    Sylvain Patenaude

    2 years ago
    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.
    Kris Wong

    Kris Wong

    2 years ago
    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

    Sylvain Patenaude

    2 years ago
    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?
    Kris Wong

    Kris Wong

    2 years ago
    an android target is incompatible with a jar output
    s

    Sylvain Patenaude

    2 years ago
    So it boils down to what it simpler to achieve between a fat aar and a fat jar, basically.
    Kris Wong

    Kris Wong

    2 years ago
    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

    Sylvain Patenaude

    2 years ago
    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...
    Kris Wong

    Kris Wong

    2 years ago
    this is why we have artifact repos/dependency management
    s

    Sylvain Patenaude

    2 years ago
    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).
    Kris Wong

    Kris Wong

    2 years ago
    what do you think gets published 😛
    s

    Sylvain Patenaude

    2 years ago
    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. 🙃