[build] Publish Mentat Android SDK to jcenter/bintray

[ncalexan]

[build] Publish Mentat Android SDK to jcenter/bintray

[pocmo]

@pocmo, can you help me get the TC secrets needed to publish like a-c does? @csadilek tells me that we're publishing to your (private?) bintray repository, which obviously isn't a long term solution, but also isn't a terrible short term solution for us.

Yes, we are using my bintray API key currently. We created a mozilla-mobile Org recently, but haven't decided on a migration path yet - and to be honest that seems to be pretty risky. In another attempt to move a library to a different group ID we somehow lost ownership and had to reclaim that - later all released artifacts under that ID disappeared from jcenter completely breaking app builds here and there. With that risk I wasn't really keen on migrating the ownership to the org so far.

The "good" news is that for a new package it doesn't really matter and with any account you can claim an org.mozilla.* group ID.

With GeckoView it currently looks like we are not going to publish to jcenter for a variety of reasons. Our hope is that we can switch to whatever the release engineering team comes up with for GV and can leave jcenter and some of its wonkiness behind.

So, yeah, I can either give you the API key (or give one of your taskcluster tasks access to the secret) or we can add you to the mozilla-mobile org and you try to publish via that one.

[zcaudate]

@ncalexan, @pocmo: I'm curious what aspects of the android build stops mentat from running on the regular jvm?

[ncalexan]

@ncalexan, @pocmo: I'm curious what aspects of the android build stops mentat from running on the regular jvm?

Nothing! In fact, after I land my initial pass at building Rust-y components, I'll move to landing my work on converting the Mentat Android SDK tests from being on-device Android tests to being in-JVM Robolectric tests. I don't think I pushed that somewhere to link, and it needs to be rebased, but I'll follow up sometime soon.

We're using JNA, so it all Just Works in the JVM.

[zcaudate]

Ah awesome. I’d be interested in help out in anyway - but more so as a consumer.

[pocmo]

I assume a regular Java developer would need a JAR instead of an AAR? Can JARs contain native libraries?

converting the Mentat Android SDK tests from being on-device Android tests to being in-JVM Robolectric tests.

Do you need Roboletric or could they be plain junit tests? If you need Roboletric then I assume you have some kind of dependency on Android that will make it hard to use the SDK on a non-Android JVM?

[ncalexan]

I assume a regular Java developer would need a JAR instead of an AAR? Can JARs contain native libraries?

Here we're really exploiting the work that JNA has done for this. The answer is yes -- JNA knows to look for native libraries (with well-known paths, etc) in the Java resources sections of the classpath. That's how it finds its own libjnidispatch. More below.

converting the Mentat Android SDK tests from being on-device Android tests to being in-JVM Robolectric tests.

Do you need Roboletric or could they be plain junit tests? If you need Roboletric then I assume you have some kind of dependency on Android that will make it hard to use the SDK on a non-Android JVM?

They could be plain JUnit tests in theory, 'cuz we're really not using anything Android specific in our Java (eventually, Kotlin?) API. But I don't want to commit to not using anything Android specific, since we're serving an Android master here. But it's clear to me that it can work on a JVM without Robolectric, even if we don't do that work.

It's neat!

[zcaudate]

Is there a doc on what is contained in the AAR file?

[ncalexan]

Is there a doc on what is contained in the AAR file?

No, but you can crack open the AAR to see. The Java SDK is in sdks/android/Mentat; it's not large, and there is Javadoc (although I'm not sure how useful it is -- patches welcome!)

[pocmo]

But I don't want to commit to not using anything Android specific, since we're serving an Android master here.

Absolutely agree with that! That's why we are just building AARs for everything in the components repository - even though some of them are just plain Java code.

[ncalexan]

Not sure why this is still open -- I landed this in fba378e