> There's no reason to use buildAar or buildApklib unless you're publishing those to maven/ivy.
Right, or its an actual android library (buildApklib). This is a usability/build-contract issue. > You cannot have libs duplicated across projects, that will result in duplicate files unless you filter them out. You can, and I have, and I've also had it where there were dups causing build issues as detailed in my earliest emails. There's a lot of possibility for variance here and no real contract to be adhered to. > Use maven/ivy dependencies properly. I can't b/c the plugin (or some part of sbt) can't seem to differentiate between a dependency of a dependencies type. Try making use of: 'com.github.chrisbanes.actionbarpulltorefresh:extra-abc:+' for example. I'm not simply finger waiving either, but have to dive into sbt more before I can effectively fix these issues [you may or may not care for] On Mon, Jan 13, 2014 at 3:03 PM, pfn <[email protected]> wrote: > 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 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.
