jayway/maven-android-plugin — pull request #413 by greek1979 (2014-07-24 12:07:21+00:00)
Title: Do not modify classpath for non-Android projects

There seems to be a compatibility issue with other Maven plugins when current project or one of its modules is packaged into a non-Android format, but has Android-specific dependencies listed within section.

An easy example would be a parent POM file that includes a dependency on an AAR artifact, which is naturally not recognized or handled in any way by default Maven setup. If the packaging type is set to "pom", AMP does not participate in build lifecycle, BUT it does modify project classpath. For each AAR or APKLIB dependency, an extra classpath entry with scope "system" is dynamically added; an entry typically points to "classes.jar" file from an unpacked AAR library. The problem here is that should any Maven plugin attempt to build or validate dependency tree for a project, it will fail as newly created JAR entry is there, but actual JAR file is not.

Same happens if some Maven plugin decides to build the dependency graph BEFORE "generate-sources" lifecycle phase. Plugin fails because classpath entry has been added, but referenced JAR file has not been unpacked yet. But this one can be workarounded by explicitly reassigning offending plugin to run at a later phase, if possible.

The proposed fix is very simple and straightforward - DO NOT modify project classpath (list of dependencies) unless this is an Android project where AVP actively participates. My only concern is this: would such a change break something? And is it in line with expected AVP usage?