Just want to add a scenario where we use Gradle version ranges very heavily running into this issue when trying to build dependent projects with Maven.

We have two teams, one working with Maven, the other having implemented a Gradle build process. This build process relies on a 3 point version X.Y.Z where X is the major version and Y is the minor version, both maintained manually by the developers according to semantic version rules. However, the Z part is maintained automatically by our build server which increments it for every release candidate it builds (also checking in the change into the source repo). We call Z the "build number".
This works very well for the Gradle-based team. Every release candidate version is ensured to be unique; there cannot be two release candidate packages with the same full qualified version number at all (as long as the build system is implemented correctly).

The build server builds the release candidates very frequently (each night) such that the Gradle team does not want to maintain the dependencies in the projects including the build number as it would become a night mare as it changes so often and in fact does not provide any additional dependency information.
As long as every developer consider the semantic version rules (which every one is required), the build number is not important for dependency maintenance. Therefore we are using dynamic versions in the form of "X.Y.+" to maintain the dependencies.
This fits well to our version model and together with the Gradle caching provides a very good build experience.

The problem come in the first time when the Maven team wanted to add a dependency to one of our components. The maven dependency resolution system just fails as it tried to get a version "X.Y.+" which of course does not exist in our Nexus repository.

An example of a Maven POM with dynamic version inside is the following:

<?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>platform-bln</groupId>
  <artifactId>javapos-config</artifactId>
  <version>1.55.32</version>
  <dependencies>
    <dependency>
      <groupId>platform-bln</groupId>
      <artifactId>javapos-jcl</artifactId>
      <version>1.1.+</version>
      <scope>runtime</scope>
    </dependency>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>thirdparty</groupId>
      <artifactId>jcl</artifactId>
      <version>2.2.0</version>
      <scope>compile</scope>
    </dependency>
  </dependencies>
</project>

So, for us it would be very helpful, if this problem could be solved.

In fact, according to the issue https://issues.gradle.org/browse/GRADLE-1578 and Nexus team note http://central.sonatype.org/articles/2014/Oct/28/enforcing-valid-dependency-versions/ I expected that this problem is already solved. Unfortunately not.

However, I would not expect a maven version syntax problem. Shouldn't a Gradle version "1.7.+" be able to be mapped to Maven's version "[1.7.0,1.8.0)" as discussed here: http://gradle.1045684.n5.nabble.com/Translating-Ivy-dep-version-syntax-to-Maven-in-POM-generation-td5712755.html?

Regards, Denis

Does anyone know a local workaround we could add to our build scripts?
Denis

After get trained by @breskeby , I found a workaround for me, I would like to share for anyone having similar problems.

The workaround replaces the Ivy/Gradle version range syntax with '+' at the end by the equivalent Maven version range syntax defined at http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html.
It uses a post configuration hook provided by the maven plugin:

uploadArchives.repositories.mavenDeployer.pom*.whenConfigured { pom ->
	pom.dependencies.each { dep -> dep.version = dep.version.replaceFirst('(\\d+(\\.\\d+)*)\\.?\\+', '[$1.0,)') }
}

The code example is derived from Example 31.7 "Modifying auto-generated content" https://docs.gradle.org/3.0/userguide/maven_plugin.html.

It should properly handle all kinds of dynamic dependency versions like 2+, 2., 3.2, 3.2., 4.2.1, 4.2.1.+ (shortly tested)

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Issue was moved to GitHub: https://github.com/gradle/gradle/issues/931

Resolving as duplicate. Thanks for the detailed reported on GitHub.