There's no reason to use buildAar or buildApklib unless you're publishing
those to maven/ivy.
You cannot have libs duplicated across projects, that will result in
duplicate files unless you filter them out. Use maven/ivy dependencies
properly.
On Monday, January 13, 2014 12:09:19 PM UTC-8, Daniel Skinner wrote:
>
> care to elaborate? There's a library project where it doesn't really
> matter if i specify androidBuildAar or AndroidBuildApklib ( .. fun, no real
> contract to adhere to here ) and a helper method for defining my 70+
> variants.
>
> On Sunday, January 12, 2014 5:21:12 PM UTC-6, pfn wrote:
>>
>> This doesn't make sense, either.
>>
>> I will update the readme once there is an official release and it is no
>> longer a snapshot.
>>
>> On Friday, January 10, 2014 6:10:03 PM UTC-8, Daniel Skinner wrote:
>>>
>>> so unmanagedBase worked out ok. Final build.scala looked like this:
>>>
>>> object FooBarBazBuild extends Build {
>>>
>>> lazy val root = Project("all", file(".")) aggregate(a, b)
>>>
>>> lazy val baz = project settings (android.Plugin.androidBuildAar: _*)
>>>
>>> lazy val fooSettings = android.Plugin.androidBuild(baz) ++ Seq(
>>> localProjects in Android += LibraryProject(baz.base),
>>> platformTarget in Android := "android-19",
>>> proguardScala in Android := true,
>>> proguardOptions in Android ++= IO.readLines(file("proguard.txt")),
>>> scalacOptions in Compile ++= Seq("-deprecation", "-feature"),
>>> javacOptions in Compile += "-deprecation",
>>> unmanagedBase := baseDirectory.value / ".." / ".." / "aaclib"
>>> )
>>>
>>> def foo(name: String): Project = Project(id = name, base =
>>> file("foos") / name) settings(fooSettings: _*) dependsOn(baz)
>>>
>>> lazy val a = foo("a")
>>> lazy val b = foo("b")
>>> }
>>>
>>> Then calling `gen-idea` and opening up worked out fine in the end using
>>> a snapshot of the official repo:
>>>
>>> resolvers += "Sonatype snapshots" at "
>>> http://oss.sonatype.org/content/repositories/snapshots/";
>>>
>>> addSbtPlugin("com.github.mpeltonen" % "sbt-idea" % "1.6.0-SNAPSHOT")
>>>
>>> Maybe worth updating the README of android-sdk-plugin since that pull
>>> request has long since been accepted.
>>>
>>>
>>> On Fri, Jan 10, 2014 at 6:43 PM, Daniel Skinner <[email protected]> wrote:
>>>
>>>> after much turmoil, the dup compiling seems to have been coming from
>>>> references to the lib in project.properties, likely conflicting with the
>>>> latter example of manually specifying LibraryProject. After some
>>>> tinkering,
>>>> I can get a full and almost-proper build but it appears that the final apk
>>>> generated does not include native shared objects from the android
>>>> library's
>>>> libs/armeabi.jar file. This seems to be an issue when it comes time to
>>>> package the apk. Placing this jar in the the main projects libs/ folder
>>>> creates a workable build (but i'm going to have 70+ variants here so
>>>> that's
>>>> not practical) and produces the following output
>>>>
>>>> Writing output...
>>>> Preparing output jar
>>>> [.../foo/bar/target/android-bin/classes.proguard.jar]
>>>> Copying resources from program jar
>>>> [.../baz/target/android-bin/classes.jar] (filtered)
>>>> Copying resources from program jar [.../foo/bar/libs/armeabi.jar]
>>>> (filtered)
>>>> Copying resources from program jar [.../baz/libs/androidutils.jar]
>>>> (filtered)
>>>> Copying resources from program jar [.../baz/libs/armeabi.jar]
>>>> (filtered)
>>>> Warning: can't write resource [lib/armeabi-v7a/gdb.setup] (Duplicate
>>>> zip entry [armeabi.jar:lib/armeabi-v7a/gdb.setup])
>>>> Warning: can't write resource [lib/armeabi-v7a/gdbserver] (Duplicate
>>>> zip entry [armeabi.jar:lib/armeabi-v7a/gdbserver])
>>>> Warning: can't write resource [lib/armeabi-v7a/libaacarray.so]
>>>> (Duplicate zip entry [armeabi.jar:lib/armeabi-v7a/libaacarray.so])
>>>> Warning: can't write resource [lib/armeabi/gdb.setup] (Duplicate zip
>>>> entry [armeabi.jar:lib/armeabi/gdb.setup])
>>>> Warning: can't write resource [lib/armeabi/gdbserver] (Duplicate zip
>>>> entry [armeabi.jar:lib/armeabi/gdbserver])
>>>> Warning: can't write resource [lib/armeabi/libaacarray.so] (Duplicate
>>>> zip entry [armeabi.jar:lib/armeabi/libaacarray.so])
>>>> Copying resources from program jar [.../baz/libs/gson-2.2.2.jar]
>>>> (filtered)
>>>> Copying resources from program jar [.../baz/libs/volley.jar]
>>>> (filtered)
>>>> Copying resources from program jar
>>>> [.../baz/libs/android-support-v4.jar] (filtered)
>>>> Copying resources from program jar
>>>> [~/.sbt/boot/scala-2.10.3/lib/scala-library.jar] (filtered)
>>>> Copying resources from program jar
>>>> [.../foo/bar/target/android-bin/classes.jar] (filtered)
>>>> [info] Creating proguard cache:
>>>> proguard-cache-3f2025f4d9ea98735795e89ab4466c3ab70cff9c.jar
>>>> [info] Generating classes.dex
>>>>
>>>> inspecting the final apk generated does show the contents of
>>>> armeabi.jar under lib/ and the app works great now, but what can I do to
>>>> avoid dropping this into the main project? My first thought is to setup
>>>> appSettings to reference the jar in unmanagedDependencies. Here's my
>>>> current build.scala
>>>>
>>>> import sbt._
>>>> import sbt.Keys._
>>>>
>>>> import android.Keys._
>>>> import android.Dependencies.LibraryProject
>>>>
>>>> object FooBarBazBuild extends Build {
>>>>
>>>> lazy val bar = project in(file("foo/bar")) settings(appSettings: _*)
>>>> dependsOn(baz) aggregate(baz)
>>>>
>>>> lazy val baz = project settings (android.Plugin.androidBuildAar: _*)
>>>>
>>>> lazy val appSettings = android.Plugin.androidBuild(baz) ++ common ++
>>>> Seq(
>>>> proguardScala in Android := true,
>>>> localProjects in Android += LibraryProject(baz.base)
>>>> )
>>>>
>>>> lazy val common = Seq(
>>>> proguardOptions in Android ++= IO.readLines(file("proguard.txt")),
>>>> scalacOptions in Compile ++= Seq("-deprecation", "-feature"),
>>>> javacOptions in Compile += "-deprecation"
>>>> )
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jan 10, 2014 at 4:52 PM, Daniel Skinner <[email protected]> wrote:
>>>>
>>>>> Even following a configuration from project tests (
>>>>> https://github.com/pfn/android-sdk-plugin/blob/master/sbt-test/android-sdk-plugin/multiproject-lib-with-resources/project/build.scala)
>>>>>
>>>>> fails with the same issue:
>>>>>
>>>>> import sbt._
>>>>> import sbt.Keys._
>>>>>
>>>>> import android.Keys._
>>>>> import android.Dependencies.LibraryProject
>>>>>
>>>>> object FooBarBazBuild extends Build {
>>>>>
>>>>> lazy val bar = project in(file("foo/bar")) settings(appSettings: _*)
>>>>> dependsOn(baz) aggregate(baz)
>>>>>
>>>>> lazy val baz = project settings (android.Plugin.androidBuildApklib:
>>>>> _*)
>>>>>
>>>>> lazy val appSettings = android.Plugin.androidBuild(baz) ++
>>>>> List(
>>>>> localProjects in Android += LibraryProject(baz.base),
>>>>> platformTarget in Android := "android-19",
>>>>> apkbuildExcludes in Android ++= Seq("META-INF/LICENSE.txt",
>>>>> "META_INF/NOTICE.txt")
>>>>> )
>>>>>
>>>>> }
>>>>>
>>>>> There's a dexInputs key it looks like I could use to filter out the
>>>>> dup classes.jar but that's still not addressing whatever is going on here.
>>>>>
>>>>>
>>>>> On Fri, Jan 10, 2014 at 4:02 PM, Daniel Skinner <[email protected]>wrote:
>>>>>
>>>>>> import sbt._
>>>>>> import sbt.Keys._
>>>>>>
>>>>>> import android.Keys._
>>>>>>
>>>>>> object FooBarBazBuild extends Build {
>>>>>>
>>>>>> lazy val bar = project in(file("foo/bar")) settings(common: _*)
>>>>>> dependsOn(baz) aggregate(baz)
>>>>>>
>>>>>> lazy val baz = project settings (common: _*)
>>>>>>
>>>>>> lazy val common = android.Plugin.androidBuild ++ Seq(
>>>>>> proguardOptions in Android ++=
>>>>>> IO.readLines(file("proguard.txt")),
>>>>>> scalacOptions in Compile ++= Seq("-deprecation", "-feature"),
>>>>>> javacOptions in Compile += "-deprecation"
>>>>>> )
>>>>>>
>>>>>> }
>>>>>>
>>>>>> So here's what ends up happening. project bar is a variant that
>>>>>> depends on android library baz. When I compile this, it appears that baz
>>>>>> is
>>>>>> compiled twice as noted by deprecation warnings. This also results in
>>>>>> bot
>>>>>> bar and baz both containing the classes from baz after calling task
>>>>>> compile. This results in all sorts of problem afterwards with the type
>>>>>> resource plugin, proguard and duplicate classes, etc. This also seems to
>>>>>> be
>>>>>> in stark contrast to a standard sbt build where classes from baz don't
>>>>>> end
>>>>>> up in bar's output.
>>>>>>
>>>>>> And in fact, if I look for bar/target/android-bin/classes.jar after
>>>>>> task compile, its not there. But if I call `android:package-debug`, then
>>>>>> the classes.jar shows up during that process and eventually causes all
>>>>>> the
>>>>>> problems when this is finally passed in to `dx`. It seems like this
>>>>>> should
>>>>>> not be happening.
>>>>>>
>>>>>> using android-sdk-plugin:1.2.5
>>>>>>
>>>>>> I wrote a custom build proc last night to help dive into the details
>>>>>> and I'm guessing I could hook in to the plugin and filter out the
>>>>>> classes.jar for project bar (since in this case the project only
>>>>>> contains
>>>>>> resource files), but I dont want to tip toe around this issue b/c what
>>>>>> if
>>>>>> it did have classes that needed to be added? Is this an issue with the
>>>>>> proguard output? or some configuration detail I'm missing?
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to a topic in
>>>>>> the Google Groups "scala-on-android" group.
>>>>>> To unsubscribe from this topic, visit
>>>>>> https://groups.google.com/d/topic/scala-on-android/5xDc-7Kodaw/unsubscribe
>>>>>> .
>>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>>> [email protected].
>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"scala-on-android" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
