Right, it has different behavior in that it creates a .aar or .apklib, one either the 'package' task or 'android:package' task, I forget which one it is. probably the former. It changes nothing in the build process itself.
On Monday, January 13, 2014 5:02:06 PM UTC-8, Daniel Skinner wrote: > > well you literally wrote "it simply has different behavior on > android:package or package, *I forget*", i just finished the thought with > a code link. > I'll keep further communication to pull requests with failed tests. > > > On Mon, Jan 13, 2014 at 6:22 PM, pfn <[email protected] <javascript:>>wrote: > >> The code should back up what I say, considering I wrote it. >> >> As for the rest, the wrappers are conveniences, maven central android >> libraries are broken. You can feel free not to use the wrapper, but you >> must exclude android-framework libraries from sonatype. >> >> >> On Monday, January 13, 2014 2:33:52 PM UTC-8, Daniel Skinner wrote: >> >>> I dont have duplicates with the current configuration unless there's a >>> library reference in the project.properties as well. That's a usability >>> issue to me as it shouldn't error out with dups at proguard, it should >>> error out during a configuration check with a clear message that there's >>> duplicate references to the same project. Ok, dont reference the same >>> project twice, but the whole issue began b/c the reference in >>> project.properties wasn't producing a successful build to begin with. I >>> have to put together more details before anything more fruitful can be >>> discussed. >>> >>> Regarding androidBuildAar and androidBuildApklib, the code is clear and >>> backs up what you say: https://github.com/pfn/android-sdk-plugin/blob/ >>> master/src/rules.scala#L62 >>> >>> Regarding dependencies, `aar(...)` and `apklib(...)`, that's probably >>> where I confused them with androidBuildAar and androidBuildApklib as I was >>> making use of `aar` and `apklib` first and foremost via managed >>> dependencies i published locally. >>> >>> In the end I had to make use of `localProjects in Android` to get >>> working builds. >>> >>> I've been down multiple paths and configurations at most a couple times, >>> and so many of those I wrote were bogus. Nearly all of them started with >>> the referenced gists in the README but in the end, the builds in the >>> android-sdk-plugin test folder were easier to understand and get something >>> going. Point being my broad generalizations on usability and build-contract >>> are derived from the numerous possible bogus configurations I was able to >>> come up with, with the intention of getting something actually working. >>> >>> The fact that I even have to wrap my managed dependencies with a helper >>> method is a usability issue in my mind. >>> The fact that I can add a managed dep on an aar, without the appropriate >>> helper function, and have it build fine but gen-idea complains b/c I need >>> the helper method is a usability issue in my mind. >>> The fact that I didn't wrap my managed dep with `aar` but it still >>> builds fine, so is it really fine? question is a usability issue. >>> All the possible bogus configurations possible when I have a clear >>> understanding of what my dependencies are but can't express it in the build >>> is a contractual issue and a documentation issue. >>> >>> Once I'm out of the "did it a couple times" phase, I'll be able to >>> address the specifics more clearly. >>> >>> >>> On Mon, Jan 13, 2014 at 3:29 PM, pfn <[email protected]> wrote: >>> >>>> Huh? There's no usability/build-contract issue. You use buildAar or >>>> buildApklib for publishing artifacts to maven/ivy, that is all. >>>> >>>> 2, if I say you cannot, then you cannot. If you have duplicates, you >>>> end up with duplicate symbols. The only way to avoid having duplicates if >>>> your project is malformed, is to weed them out manually with the various >>>> dependency and unmanagedJars keys. >>>> >>>> And can't do what of a dependency type? Don't use + in version numbers, >>>> that is bad practice. You mean it can't distinguish between transitive >>>> dependencies? you can use intransitive() or exclude() or the various >>>> aar()/apklib() helper functions. Android libraries uploaded to maven are >>>> generally all malformed due to using support-X from central rather than >>>> the >>>> local repos (impossible due to sonatype rules). >>>> >>>> >>>> On Monday, January 13, 2014 1:15:19 PM UTC-8, Daniel Skinner wrote: >>>> >>>>> > 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.tx >>>>>>>>> t")), >>>>>>>>> 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-bi >>>>>>>>>> n/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/l >>>>>>>>>> ibaacarray.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-3f2025f4d9ea987 >>>>>>>>>> 35795e89ab4466c3ab70cff9c.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-t >>>>>>>>>>> est/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-7Kod >>>>>>>>>>>> aw/unsubscribe. >>>>>>>>>>>> To unsubscribe from this group and all its topics, send an >>>>>>>>>>>> email to [email protected]. >>>>>>>>>>>> For more options, visit https://groups.google.com/grou >>>>>>>>>>>> ps/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/to >>>>>> pic/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 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] <javascript:>. >> 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.
