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] <javascript:>>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- >>>>>>>>> test/android-sdk-plugin/multiproject-lib-with-resource >>>>>>>>> s/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/ >>>> 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.
