Support libs are now AARs

[stanch]

Both support-v4 and support-v13, since version 20.0.0. What a pity!
I am not sure, but this code will probably have to be modified.

There is also another problem: in Macroid I was happily including the dependencies the simple way:

libraryDependencies ++= Seq(
  "com.google.android" % "android" % "4.1.1.4" % "provided",
  "com.android.support" % "support-v13" % "19.1.0"
)

Now that I have to unpack the AAR, it would make more sense to just use the plugin. However I don’t rely on resource ids, don’t have an AndroidManifest.xml, don’t want to publish as AAR instead of plain Scala library. Do you think I actually should? Or would it be possible to include the plugin without all that and just use aar to extract the jar from the AAR?

[pfn]

https://github.com/pfn/android-common/blob/master/build.sbt

This might do what you want

Sent from my phone
On Jul 4, 2014 2:57 PM, "Nick" notifications@github.com wrote:

Both support-v4 and support-v13, since version 20.0.0. What a pity!
I am not sure, but this code
https://github.com/pfn/android-sdk-plugin/blob/master/src/dependencies.scala#L13
will probably have to be modified.

There is also another problem: in Macroid I was happily including the
dependencies the simple way:

libraryDependencies ++= Seq(
"com.google.android" % "android" % "4.1.1.4" % "provided",
"com.android.support" % "support-v13" % "19.1.0")

Now that I have to unpack the AAR, it would make more sense to just use
the plugin. However I don’t rely on resource ids, don’t have an
AndroidManifest.xml, don’t want to publish as AAR instead of plain Scala
library. Do you think I actually should? Or would it be possible to include
the plugin without all that and just use aar to extract the jar from the
AAR?

—
Reply to this email directly or view it on GitHub
#74.

[pfn]

Ps, just compile and publish as if it were a non-android project. Don't
need any of the android: tasks.

Sent from my phone
On Jul 4, 2014 3:07 PM, "Perry Nguyen" pfnguyen@hanhuy.com wrote:

https://github.com/pfn/android-common/blob/master/build.sbt

This might do what you want

Sent from my phone
On Jul 4, 2014 2:57 PM, "Nick" notifications@github.com wrote:

Both support-v4 and support-v13, since version 20.0.0. What a pity!
I am not sure, but this code
https://github.com/pfn/android-sdk-plugin/blob/master/src/dependencies.scala#L13
will probably have to be modified.

There is also another problem: in Macroid I was happily including the
dependencies the simple way:

libraryDependencies ++= Seq(
"com.google.android" % "android" % "4.1.1.4" % "provided",
"com.android.support" % "support-v13" % "19.1.0")

Now that I have to unpack the AAR, it would make more sense to just use
the plugin. However I don’t rely on resource ids, don’t have an
AndroidManifest.xml, don’t want to publish as AAR instead of plain Scala
library. Do you think I actually should? Or would it be possible to include
the plugin without all that and just use aar to extract the jar from the
AAR?

—
Reply to this email directly or view it on GitHub
#74.

[stanch]

I decided to try publishing to AAR with android.Plugin.androidBuildAar instead. After all, maybe I’ll need to include some resources later.

Regarding my comment about that line, aar("com.android.support" % "support-v13" % "20.0.0") indeed does not work, because it excludes itself. "com.android.support" % "support-v13" % "20.0.0" works just fine, but now it seems a bit inconsistent, as the library is an AAR.

Finally, notice that support-v13 now does not include android.support.v4 package. Yeah, I know... But one needs to include both support-v13 and support-v4. This might interfere with some of the plugin’s logic as well.

[stanch]

How do I make android.Plugin.androidBuildAar publish srcs?

[stanch]

So this is due to _2.11. This fails:

aar("org.macroid" %% "macroid" % "2.0.0-20140704")

This works:

aar("org.macroid" % "macroid_2.11" % "2.0.0-20140704")

In the first case, consider this code. deps contains org.macroid:macroid — with unmangled name. moduleString(moduleForFile(...)) gives org.macroid:macroid_2.11. I am not really sure which of them is correct.

[stanch]

Ooops! Seems like my comment was not sent. This is regarding the above.

---

Could you look into this artifact? It looks ok to me, but when included with aar, the plugin just ignores it. I.e. nothing is produced by android:aars.

[stanch]

I dug a bit deeper. I think it’s an sbt bug or at least weirdness. @jsuereth

• (libraryDependencies in Compile).value.map(_.name) gives names without _2.11, while
• (update in Compile).value.configurations.flatMap(_.modules).map(_.module.name) gives names with _2.11

In the context of this plugin, it’s probably enough to cut the suffix in moduleString.

[pfn]

publishArtifact in (Compile,packageSrc) := true

I don't recall why I disabled publishing sources, I'll look at removing the
disabled setting in the plugin.

As for the module string weirdness, I'll look at making a workaround for it
next week.

Sent from my phone
On Jul 4, 2014 4:13 PM, "Nick" notifications@github.com wrote:

How do I make android.Plugin.androidBuildAar publish srcs?

—
Reply to this email directly or view it on GitHub
#74 (comment)
.

[stanch]

Thanks a lot! Just confirmed that all three sub-issues are solved. A small question: is there any particular reason why transitive AAR dependencies are not supported?

[pfn]

Because library projects pull in aar/apklib transitively, and the main project doesn't know that they're transitive and would duplicately process them. That is unwanted

[stanch]

Couldn’t the extraction of AARs/apklibs be centralized?

[pfn]

No, because they are a build dependency of the library project, and
removing them from their scope would make the library not build; drastic
changes in the build process could allow this to occur, perhaps, but I'm
not looking to consolidate all project builds into a single build
(auto-library-projects does this currently, and doesn't really play well
with intellij)

On Mon, Jul 7, 2014 at 9:45 AM, Nick notifications@github.com wrote:

Couldn’t the extraction of AARs/apklibs be centralized?

—
Reply to this email directly or view it on GitHub
#74 (comment)
.

[stanch]

Ok, I see. But how many people actually use unmanaged library projects? These days most libraries are published as AARs. Maybe unmanaged libraries could be handled by publishing and including them as AARs as well?

I think it’s a question of what should be given preference and extra ease of use — managed or unmanaged dependencies. As you may know, I am a proponent of the former and think that’s the way to go. But right now when I try to include aar("org.macroid" % "macroid" % "...") without suppor-v4, I get an awful error message along the lines of “bad reference”. This is hardly user-friendly.

Maybe this could be discussed on the mailing list?

[pfn]

bad reference as in android.support is undefined, that's a pretty clear
indicator that a user would have to add it as a library dependency. of
course, it's noted that this can easily result in a runtime error
(noclassdeffound) which would be maddening.

Unfortunately, multi-project builds are still common enough that's it's
worth transitively excluding aar.

On Mon, Jul 7, 2014 at 9:59 AM, Nick notifications@github.com wrote:

Ok, I see. But how many people actually use unmanaged library projects?
These days most libraries are published as AARs. Maybe unmanaged libraries
could be handled by publishing and including them as AARs as well?

I think it’s a question of what should be given preference and extra ease
of use — managed or unmanaged dependencies. As you may know, I am a
proponent of the former and think that’s the way to go. But right now when
I try to include aar("org.macroid" % "macroid" % "...") without suppor-v4,
I get an awful error message along the lines of “bad reference”. This is
hardly user-friendly.

Maybe this could be discussed on the mailing list?

—
Reply to this email directly or view it on GitHub
#74 (comment)
.

[stanch]

Unfortunately, multi-project builds are still common enough that's it's
worth transitively excluding aar.

Would you mind sharing your data (I’m not saying I have any myself, but my anecdotal experience obviously differs)?

[pfn]

There's no real data, but about half of the apps I build for my clients (and apps of my own) involve multi-project builds.

The multi-project builds are used mostly as a workaround for the lack of build variants.