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- >>>>>>>> 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.tx >>>>>>>>> t")), >>>>>>>>> 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 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.
