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.
