For example this is the dependency in build.gradle: compile ‘com.google.code.gson:gson:2.2.4+’
And this version tag will be generated: 2.2.4+
It seems the maven plugin just copies the version number, but ranges have a different syntax in maven, so the generated poms are invalid. 
This happens with the maven plugin and the maven-publish plugin, too.
You are right in that no translation will take place. However, Gradle does support Maven dependency range syntax, so you can use that instead of ‘+’.
Thanks for your quick answer!
However, Gradle does support Maven dependency range syntax.
You mean if the published POM is using the maven syntax, gradle cannot pull them? That’s right, but now maven cannot pull them. 
For now, if a library author let users to use maven, he must use fixed dependency versions, or ask users the exclude the dep and re-declare in pom.xml. It is just weird that lot of libs are published to maven central, with a maven pom, and has an invalid version so maven users cannot use them simply.
I know you are not concerned about maven, and it is actually a competitor, but is there really no way to resolve this conflict about versions?
I am stupid, i just read that Gradle cannot use maven syntax, but you wrote it indeed can… In that case i think the maven plugin should really translate the version and generate a valid pom.
I think there is a misunderstanding here. What I tried to convey is that Maven version range syntax can be used in Gradle build scripts. Every Gradle build that wants to use version ranges and publish them in its POM should use the Maven syntax to begin with (or post-process the POM before publishing). Also, Gradle shouldn’t have any problems consuming POMs containing Maven-style version ranges.
Automatic conversion between Ivy and Maven version range syntax might be a good thing to have (this is http://issues.gradle.org/browse/GRADLE-1578). If you are interested in contributing such a feature, please take this to the ‘gradle-dev’ list.
Just to be clear, I didn’t see your latest post until after I had written this one.
For reference, here is the gradle-dev thread.
A fix for this has been created in Gradle and will be released with 2.3 from all I know. In the meantime the Central Repository will soon block deployments with these sub-revision version syntax usage.
Please find more details at http://central.sonatype.org/articles/2014/Nov/28/enforcing-valid-dependency-versions/