mozilla
/
application-services
зеркало из
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
application-services/gradle.properties

26 строки
1.1 KiB
Properties
Исходник Постоянная ссылка Обычный вид История

Initial logins API for android (#145) This is still more or less a WIP, but at markh's recommendation I'm going to try and get it landed soon, rather than wait for it to be perfect. Things I don't like/known issues. - SyncResult is just stolen 100% from fxa crate's FxaResult. It's unclear what the right call here is though. - init_logging() in the sync15_passwords_state_new. - Errors are always strings. - Possibly the fact that we're using kotlin coroutines? I mostly cargo-culted it from fxa, but I get a warning during builds that it's experimental, and I think we could just use a thread pool or something without that much more work.
2018-08-03 21:12:41 +03:00
# Project-wide Gradle settings.
# IDE (e.g. Android Studio) users:
# Gradle settings configured through the IDE *will override*
# any settings specified in this file.
# For more details on how to configure your build environment visit
# http://www.gradle.org/docs/current/userguide/build_environment.html
# Specifies the JVM arguments used for the daemon process.
# The setting is particularly useful for tweaking memory settings.
org.gradle.jvmargs=-Xmx1536m
# When configured, Gradle will run in incubating parallel mode.
# This option should only be used with decoupled projects. More details, visit
# http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:decoupled_projects
# org.gradle.parallel=true
Publish logins AAR to nalexander's personal bintray. (Fixes #189) (#199) r=vladikoff,tcsc * Pre: Bump version to 0.3.2. This just needs to be greater than 0.3.1, the last version I pushed in testing. * Publish logins AAR to nalexander's personal bintray. * Post: Bump task timeout for build and publishing. Building everything for three architectures just takes a long time -- 15 minutes per architecture or more. I investigated speeding this up, and I conclude that compiling the architectures in parallel is both work (you need to work around cargo a little bit, and you need to use a Make jobserver to limit the total thread pool) and doesn't pay off (I witnessed only about a 5-10% speed-up locally). My guess is that it pays off even less in AWS, where IO throughput is relatively low and context switching relatively more expensive.
2018-09-12 21:39:25 +03:00
Move everything under org.mozilla.appservices
2019-03-14 20:42:07 +03:00
libGroupId=org.mozilla.appservices
Publish logins AAR to nalexander's personal bintray. (Fixes #189) (#199) r=vladikoff,tcsc * Pre: Bump version to 0.3.2. This just needs to be greater than 0.3.1, the last version I pushed in testing. * Publish logins AAR to nalexander's personal bintray. * Post: Bump task timeout for build and publishing. Building everything for three architectures just takes a long time -- 15 minutes per architecture or more. I investigated speeding this up, and I conclude that compiling the architectures in parallel is both work (you need to work around cargo a little bit, and you need to use a Make jobserver to limit the total thread pool) and doesn't pay off (I witnessed only about a 5-10% speed-up locally). My guess is that it pays off even less in AWS, where IO throughput is relatively low and context switching relatively more expensive.
2018-09-12 21:39:25 +03:00
libRepositoryName=application-services
Publish all Maven artifacts to a single bintray package. Right now, we publish each Maven artifact "cluster" -- for "logins", say, that is "logins", "logins-withoutLibs", and "logins-forUnitTests" -- to a single bintray package named like the Maven artifact ID (say, "logins"). This seems to be common, but bintray mirrors packages to jcenter, and bintray packages don't map directly to Maven coordinates. AFAICT, that is the thing that requires somebody (right now, me -- nalexander) to push the "mirror to jcenter" button in the bintray UI. If we instead have a single bintray "package" (say, "org.mozilla.appservices") and then publish many Maven artifacts to that package, we should get automatic jcenter mirroring for everything that we have under it. Let's try!
2019-03-16 01:35:33 +03:00
libProjectName=org.mozilla.appservices
Publish logins AAR to nalexander's personal bintray. (Fixes #189) (#199) r=vladikoff,tcsc * Pre: Bump version to 0.3.2. This just needs to be greater than 0.3.1, the last version I pushed in testing. * Publish logins AAR to nalexander's personal bintray. * Post: Bump task timeout for build and publishing. Building everything for three architectures just takes a long time -- 15 minutes per architecture or more. I investigated speeding this up, and I conclude that compiling the architectures in parallel is both work (you need to work around cargo a little bit, and you need to use a Make jobserver to limit the total thread pool) and doesn't pay off (I witnessed only about a 5-10% speed-up locally). My guess is that it pays off even less in AWS, where IO throughput is relatively low and context switching relatively more expensive.
2018-09-12 21:39:25 +03:00
libProjectDescription=Firefox Application Services
libUrl=https://github.com/mozilla/application-services
libVcsUrl=https://github.com/mozilla/application-services.git
libLicense=MPL-2.0
libLicenseUrl=https://www.mozilla.org/en-US/MPL/2.0/
Update Android dependencies
2020-04-07 19:51:42 +03:00
android.useAndroidX=true