Gradle bug avoid to use AAR libraries by Maven

[Tomáš Procházka]

I really hate Gradle, everything is buggy and much slower than maven.

But one bug in gradle is specially very annoying

Gradle don't create <type> element in the pom if you deploy multi module AAR project like https://github.com/ManuelPeinado/FadingActionBar

And maven central allow to upload this incorrect pom  :-(

Here is bug report to the Gradle dev mailing list

http://gradle.1045684.n5.nabble.com/Publishing-a-maven-artifact-depending-on-an-aar-or-other-non-quot-jar-quot-artifacts-td5713019.html

But no reply yet :-(

And here is more related information to the bug

https://groups.google.com/forum/#!topic/adt-dev/PM50ZXFXN_k

https://code.google.com/p/android/issues/detail?id=72807

[William Ferguson]

Manfred, was there any follow up on the Maven Hangout about having central/Sonatype enforce the validity of uploaded POMs?

William

[Malachi de Ælfweald]

Per the comments in the referenced bug, it appears to be a Gradle issue.
But that does leave us with stale/broken poms in the repo.  Do we leave them and tell people to republish once Gradle is fixed?

Malachi de Ælfweald
http://www.google.com/profiles/malachid

--
You received this message because you are subscribed to the Google Groups "Maven Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to maven-android-deve...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tomáš Procházka]

This bug affect also dependencies distributed by Google, for example we can't use this

<dependency>
			<groupId>com.android.support</groupId>
			<artifactId>appcompat-v7</artifactId>
			<type>aar</type>
</dependency>

And yes will be neccesary to republish all artefact that use another aar as dependency.

Dne pátek, 5. září 2014 17:40:33 UTC+2 Malachi de Ælfweald napsal(a):

To unsubscribe from this group and stop receiving emails from it, send an email to maven-android-developers+unsub...@googlegroups.com.

[Malachi de Ælfweald]

This is the $ANDROID_HOME/extras/android/m2repository/com/android/support/appcompat-v7/21.0.0-rc1/appcompat-v7-21.0.0-rc1.pom

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.android.support</groupId>
  <artifactId>appcompat-v7</artifactId>

  <version>21.0.0-rc1</version>
  <packaging>aar</packaging>
  <dependencies>
    <dependency>
      <groupId>com.android.support</groupId>
      <artifactId>support-v4</artifactId>
      <version>21.0.0-rc1</version>
      <scope>compile</scope>
    </dependency>
  </dependencies>
</project>

As we were discussing, their dependency incorrectly left off the type.

You CAN however tell it to ignore their dependency:
            <exclusions>
                <exclusion>
                    <groupId>com.android.support</groupId>
                    <artifactId>support-v4</artifactId>
                </exclusion>
            </exclusions>

Which will then let you explicitly add the support-v4 dependency correct.

It's definitely a hacky workaround, but it should get you moving forward.

Malachi de Ælfweald
http://www.google.com/profiles/malachid

To unsubscribe from this group and stop receiving emails from it, send an email to maven-android-deve...@googlegroups.com.

[Csaba Kozák]

Actually gradle really does maven users in the eye.
See this POM, generated by gradle. A dependency uses the Ivy version syntax, which brakes Maven dependency resolution.
And this was also allowed in central...

[Tomáš Procházka]

I fixed pom file in google SDK directory manually and deploy to our nexus repo by maven-android-sdk-deployer and it works.

Dne pátek, 5. září 2014 19:34:24 UTC+2 Malachi de Ælfweald napsal(a):

To unsubscribe from this group and stop receiving emails from it, send an email to maven-android-developers+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[William Ferguson]

Yeah, this whole

<version>19.1.+</version>

nonsense has got to be stopped from spreading.




Manfred, is Sonatype in a position to reject malformed POMs?

--
You received this message because you are subscribed to a topic in the Google Groups "Maven Android Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/maven-android-developers/iOvEgkkpOKk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to maven-android-deve...@googlegroups.com.

[Csaba Kozák]

Manfred, i am also very interested in this.

[Manfred Moser]

I have talked to Hans Dockter at JavaOne and we are actively working to resolve this issue. It will require coordination with a second issue from the sbt community and we are going to roll out an enforcement in OSSRH once solutions exist.

Stay tuned.

Manfred

Csaba Kozák wrote on 01.10.2014 11:12:

> Manfred, i am also very interested in this.

> --
> You received this message because you are subscribed to the Google Groups "Maven Android Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to maven-android-deve...@googlegroups.com <mailto:maven-android-deve...@googlegroups.com> .
> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout> .

[Csaba Kozák]

Manfred, thanks for the answer! This is really great  news. Actually i opened a bug against gradle, and we had some discussion about the solution ( http://gradle.1045684.n5.nabble.com/Translating-Ivy-dep-version-syntax-to-Maven-in-POM-generation-td5712755.html#a5713082). Unfortunetaly i will not have the time (nor the experience on gradle codebase) to contribute the fix. But i guess others will implement it soon as Manfred said.

[Csaba Kozák]

OK, i can confirm the most basic problem has been fixed in Gradle.
But it do not know when this will go into a public release.

[Manfred Moser]

I implemented the validation as part of deployment to OSSRH and therefore to the Central Repository.

Problem of course is that 

1. inside their own repo they ship with the SDK Google can (and does) screw up as much as they want

2. the default repo for the new Gradle build system is Jcenter/bintray and they dont have a policy around this at all. 

This is an uphill task.. 

Manfred