Support 'android' as well as 'com.google.android' as group ids.

[kingargyle]

The maven android sdk deployer by default uses 'android' as the group id instead
of com.google.android. I believe google with Gradle is starting to move toward
the com.google.android groupID but for legacy projects the 'android' groupID still
needs to be supported otherwise projects can't be configured.

[rgladwell]

Looks good but I can't merge this without an integration test. Please add.

[kingargyle]

Will work on the integration test. I'll take a look at the existing tests for examples.

[rgladwell]

@kingargyle thanks, much appreciated. Although you may have some problems writing test if groupId "android" artefacts aren't in Maven Central.

[kingargyle]

Yeah, that is another problem. The lookup always seems to go to the remote repository, and doesn't appear to look in the local repository for items. It should try and check the local repository first, and then central. Haven't looked into it too much for why this currently happens.

[rgladwell]

I think it is checking the local repository first, that is the default behaviour. It might just be running as a different user and not using your personal $HOME/.m2/repository directory.

But remember, this integration tests run in Travis and other environments so we can't always guarantee we'll be able to run the maven-android-sdk-deployer.

[kingargyle]

Yeah, will probably need to mock some things out to make it platform neutral. Will be a bit before I can get back to this

[rgladwell]

This looks like a fix for #181

[rgladwell]

I think the best solution for the problems with absent maven-android-sdk-deployer "android" groupId artefacts is to add the maven-android-sdk-deployer to the build process, both in the README and in the .travis.yml build descriptor.

[kingargyle]

That should get around the problem.

[rgladwell]

Another alternative is to import the maven-sdk-deployer into m2e-android directly so, it encounters an android group id, it automatically imports the relevant SDK binary into you local repo

[rgladwell]

Even with this fix, the code still errors with the following error message:

Caused by: me.gladwell.eclipse.m2e.android.configuration.ProjectConfigurationException: org.sonatype.aether.resolution.ArtifactResolutionException: Could not find artifact android:android:jar:4.4_r1 in central (http://repo1.maven.org/maven2/)
    at me.gladwell.eclipse.m2e.android.resolve.AetherArtifactResolver.resolveArtifact(AetherArtifactResolver.java:44)
    at me.gladwell.eclipse.m2e.android.resolve.AetherDependencyResolver.resolveDependencies(AetherDependencyResolver.java:57)
    at me.gladwell.eclipse.m2e.android.resolve.AetherDependencyResolver.resolveDependencies(AetherDependencyResolver.java:44)
    at me.gladwell.eclipse.m2e.android.project.JaywayMavenAndroidProject.getPlatformProvidedDependencies(JaywayMavenAndroidProject.java:88)
    at me.gladwell.eclipse.m2e.android.configuration.PrunePlatformProvidedDependenciesClasspathLoader.load(PrunePlatformProvidedDependenciesClasspathLoader.java:47)
    at me.gladwell.eclipse.m2e.android.configuration.NonRuntimeDependenciesClasspathContainer.getClasspathEntries(NonRuntimeDependenciesClasspathContainer.java:39)
    at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2698)
    at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2615)
    at org.eclipse.jdt.internal.core.ClasspathEntry.validateClasspath(ClasspathEntry.java:1649)
    at org.eclipse.jdt.internal.core.SetClasspathOperation.verify(SetClasspathOperation.java:118)
    at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:782)
    at org.eclipse.jdt.internal.core.JavaProject.setRawClasspath(JavaProject.java:3096)
    at org.eclipse.jdt.internal.core.JavaProject.setRawClasspath(JavaProject.java:3058)
    at org.eclipse.jdt.internal.core.JavaProject.setRawClasspath(JavaProject.java:3070)
    at org.eclipse.m2e.jdt.internal.AbstractJavaProjectConfigurator.configure(AbstractJavaProjectConfigurator.java:141)
    at me.gladwell.eclipse.m2e.android.AndroidMavenProjectConfigurator.configure(AndroidMavenProjectConfigurator.java:69)
    ... 65 more
Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Could not find artifact android:android:jar:4.4_r1 in central (http://repo1.maven.org/maven2/)
    at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:538)
    at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:216)
    at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:193)
    at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:286)
    at me.gladwell.eclipse.m2e.android.resolve.AetherArtifactResolver.resolveArtifact(AetherArtifactResolver.java:41)
    ... 80 more
Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact android:android:jar:4.4_r1 in central (http://repo1.maven.org/maven2/)
    at org.sonatype.aether.connector.async.AsyncRepositoryConnector$3.wrap(AsyncRepositoryConnector.java:1542)
    at org.sonatype.aether.connector.async.AsyncRepositoryConnector$3.wrap(AsyncRepositoryConnector.java:1537)
    at org.sonatype.aether.connector.async.AsyncRepositoryConnector$GetTask.flush(AsyncRepositoryConnector.java:1035)
    at org.sonatype.aether.connector.async.AsyncRepositoryConnector.get(AsyncRepositoryConnector.java:409)
    at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:457)
    ... 84 more

Looks as though m2e-android tries to resolve the dependencies remotely even though they're only available locally.

[rgladwell]

OK I fixed the above but there is a further problem: the Android API dependencies deployed by the Android Maven SDK Deployer do not contain references to the other APIs (httpcomponents, etc) bundled with the Android Platform.

This causes the following tests to fail:

testConfigureAddsPlatformProvidedDependenciesToTestRunnerClasspath
testConfigureAddsTransitivePlatformProvidedDependenciesToTestRunnerClasspath

Maybe these aren't important although this is annoying.

[WonderCsabo]

BTW do you think the artifacts deployed by the Deployer should contain these references?

[kingargyle]

The HTTPComponents from Apache are deprecated anyways. Most people will replace it with their own Http Client, or use the URLConnection items, which is where Android is trying to push people.

[rgladwell]

@WonderCsabo if the old dependencies published by Google had references to platform provided dependencies like common-logging or httpclient (its not just httpclient @kingargyle) the new ones should too I feel.

At the moment I've hacked a fix for this, but maybe we should raise this with the upstream project?

[rgladwell]

Rebased into commit 2367ded

[WonderCsabo]

By "the upstream project", you mean the Maven Android SDK Deployer? Actually i am not competent on the matter, but it's free to open a ticket. :)

[kingargyle]

We usually have to end up excluding the commons-logging in our builds, because of proguard warnings if we use the com.google.android versions from maven central. I believe the maven sdk deployer doesn't specifically include them because those libraries are provided in the android jar that get deployed. Either way, we'll just specifically exclude the dependencies that are not necessary in our particular builds.

[rgladwell]

CI fixed. This update should now be available from the snapshot update site:

http://rgladwell.github.io/m2e-android/updates/master/

If you're using m2e-android commercially or you'd like to see more frequent releases please consider crowdfunding me through my Patreon profile.

[rgladwell]

@kingargyle I'm confused, you I thought commons-logging was provided as part of the Android platform and should only be used as a provided-scope dependency in Android projects? You shouldn't need to ProGuard?

[kingargyle]

If you specifically bring in the Apache Commons HTTP dependency, it'll also bring in the apache-commons dependency as well. We had to specifically mark the apache commons as provided in our build so it wouldn't get included. Anyways, just something we have to keep in mind. Personally I think the android maven sdk deployer is correct in the way it is handling it. As the android.jar that is deployed typically already has all those dependency packages included in the jar.

[rgladwell]

@kingargyle why would you specifically include the Commons HTTP dependency? Can I confirm, the Android platform dependencies added by the Android Maven SDK Deployer include platform-provided dependencies like HTTP client?

[kingargyle]

The reason we include the HTTP Client specifically (which has it's own dependency on HTTP Commons Logging), is that we needed bug fixes and other items that are in the newer versions of HTTP Client. The version included in the android.jar is several versions behind, and isn't being updated any more. Only the stubs are included in the android.jar, so yes you are correct that the HTTP Client dependency is needed if you are going to run unit tests. Robolectric doesn't need it because it intercepts the DefaultClient constructor and provides a shadow for it.

I opened the android.jar that is deployed by android maven adk deployer, and it contains both the apache http client, and the apache commons classes. This is why you can compile and write code, but need to use something like Robolectric to run unit tests natively.

What it doesn't do is specifically put additional dependencies, when it is deploying the jar to the local maven repository. It is just using the file-deploy goal of the maven deploy plugin.

[rgladwell]

@kingargyle so does the HTTP client bundled in your APK override the one provided on Android devices?

Thanks for checking that, sounds like we won't need the code that filters out the Android platform-provided dependencies from the Eclipse classpath in future. I always thought it was a bit odd Google included things like httpclient in the first place.

[rgladwell]

@kingargyle BTW can you please check if the latest snapshot code is working as you expect?

[kingargyle]

Yes, the one bundled in your APK takes precedence over the one bundled with Android itself.

Latest snapshot is working, as my own project we use the android groupid instead of com.google.android.

[rgladwell]

@kingargyle 👍