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]> 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/conte >>>>>>>> nt/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/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-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.tx >>>>>>>>> t")), >>>>>>>>> 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/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/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]. > 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.
