Samples libraryprojects/libraryprojects-tests fails about android-maven-plugin HOT 7 CLOSED

NB to get this far you also need to have changed the scope of the APK dependency in libraryprojects-tests/POM.xml to provided. Eg

    <dependency>
      <groupId>com.jayway.maven.plugins.android.generation2.samples.libraryprojects</groupId>
      <artifactId>libraryprojects-apk-with-deps</artifactId>
      <version>${project.version}</version>
      <type>apk</type>
      <scope>provided</scope>
    </dependency>

from android-maven-plugin.

@malachid suggested using isEnableIntegrationTest to determine whether it is an instrumentation test. A better approach is extractInstrumentationRunnerFromAndroidManifest(manifestFile) != null as we can call it from any AndroidMojo not just an InstrumentationMojo.

from android-maven-plugin.

That's a good idea

from android-maven-plugin.

We're moving the email thread to here....

I had noted that I got the tests to compile and run by changing the dependency to:

    <dependency>
      <groupId>com.jayway.maven.plugins.android.generation2.samples.libraryprojects</groupId>
      <artifactId>libraryprojects-apk-with-deps</artifactId>
      <version>${project.version}</version>
      <type>apk</type>
      <scope>provided</scope>
      <exclusions>
       <exclusion>
        <groupId>com.jayway.maven.plugins.android.generation2.samples.libraryprojects</groupId>
        <artifactId>libraryprojects-apklib-from-apklib</artifactId>
       </exclusion>
      </exclusions>
    </dependency>

Not ideal. With normal APK, we would include the source from APKLIB into the APK. With an instrumentation APK, we should not be embedding the classes from any of the dependencies.

The previous mentioned fix was regarding AAR classpath being setup, but unpacked_libs not existing. Now, the 'extract into unpacked_libs' (and no other step) is allowing provided scope.

I think we can fix this pretty easily and cleanly. We don't even need to look at the AndroidManifest. We normally extract the APKLIB and include it in the source set to compile. If the APKLIB is set to system|provided (actually our normal exclusion rules) we don't add it as a source set... Then normal APKLIBs that declare a chained dependency are still OK; APKs that declare an APKLIB dependency are still OK; but transitive APKLIBs coming from provided-scope APK will have the scope of provided and be ignored...?

from android-maven-plugin.

I got lost on how a APKLIB dep of an APK dep would not be included.

I actually have a solution that I am running through some final tests.
It build ands runs the samples end to end on the Dalvik runtime.

I just want to test it on @malachid's #358 test project.

from android-maven-plugin.

sweet =)

from android-maven-plugin.

Fix merged

from android-maven-plugin.