greg/mentat

Fork 0

[build] Publish Mentat Android SDK to jcenter/bintray #4

New issue

Open

opened 2020-08-06 14:55:26 +00:00 by gburd · 10 comments

gburd commented

2020-08-06 14:55:26 +00:00

(Migrated from github.com)

android-components have a pleasant setup for publishing to jcenter/bintray. I have work in progress on doing this for Mentat, using exactly the same setup; see https://github.com/mozilla/mentat/tree/build-android-sdk. There's some details to work out with getting Rust and the Android NDK configure correctly in a Docker image, but I have no doubt that this can be achieved.

This ticket tracks getting the "final mile" worked out: once we have things building, getting credentials to publish to the right namespace. I'd prefer org.mozilla.mentat, but I don't feel too strongly about it.

@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.

Original by @ncalexan

[android-components](https://github.com/mozilla-mobile/android-components) have a pleasant setup for publishing to jcenter/bintray. I have work in progress on doing this for Mentat, using exactly the same setup; see https://github.com/mozilla/mentat/tree/build-android-sdk. There's some details to work out with getting Rust and the Android NDK configure correctly in a Docker image, but I have no doubt that this can be achieved. This ticket tracks getting the "final mile" worked out: once we have things building, getting credentials to publish to the right namespace. I'd prefer `org.mozilla.mentat`, but I don't feel too strongly about it. @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. Original by @ncalexan

gburd commented

2020-08-06 14:55:27 +00:00

(Migrated from github.com)

@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.

Original by @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. Original by @pocmo

gburd commented

2020-08-06 14:55:28 +00:00

(Migrated from github.com)

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

Original by @zcaudate

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

gburd commented

2020-08-06 14:55:29 +00:00

(Migrated from github.com)

@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.

Original by @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. Original by @ncalexan

gburd commented

2020-08-06 14:55:29 +00:00

(Migrated from github.com)

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

Original by @zcaudate

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

gburd commented

2020-08-06 14:55:30 +00:00

(Migrated from github.com)

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?

Original by @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? Original by @pocmo

gburd commented

2020-08-06 14:55:31 +00:00

(Migrated from github.com)

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!

Original by @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! Original by @ncalexan

gburd commented

2020-08-06 14:55:32 +00:00

(Migrated from github.com)

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

Original by @zcaudate

Is there a doc on what is contained in the AAR file? Original by @zcaudate

gburd commented

2020-08-06 14:55:33 +00:00

(Migrated from github.com)

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!)

Original by @ncalexan

> Is there a doc on what is contained in the AAR file? No, but you can crack open the [AAR](https://bintray.com/ncalexander/mentat/download_file?file_path=org%2Fmozilla%2Fmentat%2Fmentat%2F0.10.0%2Fmentat-0.10.0.aar) to see. The Java SDK is in `sdks/android/Mentat`; it's not large, and there is [Javadoc](https://mozilla.github.io/mentat/apis/latest/java/index.html) (although I'm not sure how useful it is -- patches welcome!) Original by @ncalexan

gburd commented

2020-08-06 14:55:33 +00:00

(Migrated from github.com)

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.

Original by @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. Original by @pocmo

gburd commented

2020-08-06 14:55:34 +00:00

(Migrated from github.com)

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

Original by @ncalexan

Not sure why this is still open -- I landed this in https://github.com/mozilla/mentat/commit/fba378ee394cad7f373b1623f1a74dadc3999110 Original by @ncalexan