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] <javascript:>>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] <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.
