android-support: create modules for apklib and aarlib dependencies

[stanch]

Hi,

Currently neither apklib, nor aar dependencies are added as IDEA modules (while their own binary dependencies are). The latest snapshot of android-plugin from @fxthomas generates them in target/scala-$scalaVesion/apklib_managed/src and target/scala-$scalaVersion/aarlib_managed/lib respectively. Note that the former consists of sources, while the latter consists of binaries.

This could probably be addressed in @fxthomas’ fork [1], also see discussion here: [2].

[1] https://github.com/fxthomas/sbt-idea [2] https://groups.google.com/d/msg/scala-on-android/GPyUXssicLY/s14p2xrTFLIJ

Kind regards, Nick

[fxthomas]

A pointer : any idea why the external dependency classpath is only retrieved from the test configuration in [1]?

The AAR library JAR gets added to managedClasspath in Compile, but not to managedClasspath in Test, which is why sbt-idea doesn't find it. We might want to add it to test as well in sbt-android, now that I think of it.

[1] https://github.com/mpeltonen/sbt-idea/blob/sbt-0.12/src/main/scala/org/sbtidea/SbtIdeaModuleMapping.scala#L40

[fxthomas]

I ended up using the unmanaged classpath, and things look better. Adding managed libraries by hand is probably not the way to go, even though they are managed, in a way.

ApkLibs aren't included as modules, but directly as the extracted source files, so they should work directly.

However, resources for both ApkLibs and AAR libs won't work, I'm trying to find a way.

[mpeltonen]

A pointer : any idea why the external dependency classpath is only retrieved from the test configuration in [1]?

I think it is that way because 'externalDependencyClasspath in Test' configuration seems to be a superset of Compile, i.e. it contains all managed dependencies of Compile at least in normal case.

It may be that it's not a good practice to add stuff to 'managedClasspath in Compile' by hand, as you say.