# 2.8, 2.9 mavenDeployer doesn't honour uniqueVersion=false in maven uploadArchives **URL:** \ **Category:** Bugs\ **Tags:** gradle-3405, issue-acknowledged\ **Created:** [December 18, 2015, 6:54am UTC](https://discuss.gradle.org/t/2-8-2-9-mavendeployer-doesnt-honour-uniqueversion-false-in-maven-uploadarchives/13370 "2015-12-18T06:54:23Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Warren](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/warren/32/7063_2.png) [@Warren](https://discuss.gradle.org/u/Warren)\ **Post date:** [December 18, 2015, 6:54am UTC](https://discuss.gradle.org/t/2-8-2-9-mavendeployer-doesnt-honour-uniqueversion-false-in-maven-uploadarchives/13370/1 "2015-12-18T06:54:23Z")
I’m trying to upgrade from 2.4 to 2.9 but my uploadArchives task is generating a pom with a timestamp, making all our snapshots unique. We use a non-unique policy so we set uniqueVersion=false I reverted to 2.4 and tried to go through the versions step by step: 2.5,2.6,2.7 all failed to deploy as per [[2.7-rc-2] Cannot deploy using Maven plugin (No connector available)](https://discuss.gradle.org/t/2-7-rc-2-cannot-deploy-using-maven-plugin-no-connector-available/11563) 2.8,29 work but add the extra timestamp which I don’t want, e.g. ``` com.spindrift Common-Commerce 1.0.12-SNAPSHOT 20151218.064219 152 20151218064219 ``` This causes downstream project dependency failures because they can’t find the non-unique snapshot (i.e. without timestamp). The maven repository uses scpexe protocol so I can’t use the newer maven-publish plugin as an alternative. ---
**Author:** ![Warren](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/warren/32/7063_2.png) [@Warren](https://discuss.gradle.org/u/Warren)\ **Post date:** [December 18, 2015, 9:14am UTC](https://discuss.gradle.org/t/2-8-2-9-mavendeployer-doesnt-honour-uniqueversion-false-in-maven-uploadarchives/13370/2 "2015-12-18T09:14:32Z")
I found this issue, which I think highlights the same thing: [https://issues.gradle.org/browse/GRADLE-2711](https://issues.gradle.org/browse/GRADLE-2711) but that was back at version 1.4 We’ve been using the uniqueVersion=false for a long time and it still works for 2.4 but seems broken since 2.8 ---
**Author:** ![daz](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/daz/32/2475_2.png) [@daz](https://discuss.gradle.org/u/daz)\ **Post date:** [January 5, 2016, 3:29am UTC](https://discuss.gradle.org/t/2-8-2-9-mavendeployer-doesnt-honour-uniqueversion-false-in-maven-uploadarchives/13370/3 "2016-01-05T03:29:26Z")
I think this could be an unforeseen result of upgrading to use the Maven 3 libraries for publishing, which [happened in Gradle 2.5](https://docs.gradle.org/2.5/release-notes#maven-publishing). To clarify, do the artifacts get published with the correct extension? Is it just the `maven-metadata.xml` that is incorrectly generated, in that it contains a `timestamp` element? If so, how does this affect the downstream consumers of the publication? We have [integration test coverage](https://github.com/gradle/gradle/blob/master/subprojects/maven/src/integTest/groovy/org/gradle/integtests/publish/maven/MavenNonUniqueSnapshotPublishIntegrationTest.groovy) for the `uniqueVersion` setting, but this doesn’t validate the content of `maven-metadata.xml`. ---
**Author:** ![Warren](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/warren/32/7063_2.png) [@Warren](https://discuss.gradle.org/u/Warren)\ **Post date:** [January 5, 2016, 9:01am UTC](https://discuss.gradle.org/t/2-8-2-9-mavendeployer-doesnt-honour-uniqueversion-false-in-maven-uploadarchives/13370/4 "2016-01-05T09:01:04Z")
> [@daz](#): > > happened in Gradle 2.5 I think the issue is a little clouded by the upgrade from M2 to M3 which I had missed. > do the artifacts get published with the correct extension Yes they still get published with the same format as before, just the maven-metadata.xml that now includes a timestamp. I think under M2 it would actually publish to a separate endpoint with the timestamp, but with the upgrade and using the same configuration it does not publish with a timestamp endpoint, but because of the timestamp in the metadata a dependency consumer fails with: ` error 05-Jan-2016 08:38:54 > Could not find com.spindrift:Common-Commerce:1.0.12-SNAPSHOT. error 05-Jan-2016 08:38:54 https://myrepo/com/spindrift/Common-Commerce/1.0.12-SNAPSHOT/maven-metadata.xml error 05-Jan-2016 08:38:54 https://myrepo/com/spindrift/Common-Commerce/1.0.12-SNAPSHOT/Common-Commerce-1.0.12-20160105.083609-185.pom error 05-Jan-2016 08:38:54 https://myrepo/com/spindrift/Common-Commerce/1.0.12-SNAPSHOT/Common-Commerce-1.0.12-20160105.083609-185.jar ` I’ve looked at [Maven 3.x Compatibility Notes - Apache Maven - Apache Software Foundation](https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-VersionComparison) and it says: > Snapshot Updates > Due to implementation differences, Maven 3 and Maven 2 use different files in the local repository to track metadata. For users that employ Maven 2 and Maven 3 (or integrators of Maven 3 like M2Eclipse) side by side on the same projects, this causes both Maven versions to independently check for updates of snapshot artifacts. In other words, even if one Maven version just checked for snapshot updates, the other Maven version will do again. > Non-unique Snapshot Deployments > The setting false for a distribution repository has no effect in version 3.x, snapshot artifacts will always be deployed using a timestamped version. So our old configuration of setting false for the upload is no longer supported by M3. The curious thing is that using gradle 2.10 and uploading the jars they were not added with a timestamp end-point that the consumer expected (unless its my misunderstanding of what that format is). The way we were using snapshots was simply like a release and each snapshot simply got overwritten on each CI build so each consumer always got the latest release. I think we were implicitly relying on Gradle to ensure the snapshot dependencies were up to date by using --refresh-dependencies. So from what I can make of this is that our snapshot policy and the way we use them is no longer supported under M3 and we need to refactor the way we use snapshots going forward before we can upgrade. I will assume this is the case so please correct me if I’m wrong. Thanks ---
**Author:** ![rockympls](https://avatars.discourse-cdn.com/v4/letter/r/9fc348/32.png) [@rockympls](https://discuss.gradle.org/u/rockympls)\ **Post date:** [February 18, 2016, 10:39pm UTC](https://discuss.gradle.org/t/2-8-2-9-mavendeployer-doesnt-honour-uniqueversion-false-in-maven-uploadarchives/13370/5 "2016-02-18T22:39:22Z")
Daz - I’m having a similar problem. The short answer is **yes** to both. My thinking is that maven-metadata.xml is being generated incorrectly. When the time comes to resolve the dependency, it appears that Gradle follows the `timestamp` and `buildNumber` elements. So if those are set to 2016-02-18-163800 and 2, it would look for `my-dep-SNAPSHOT-2016-02-18-163800-2.jar` instead of just `my-dep-SNAPSHOT.jar`. Do you know of any workaround for this? ---
**Author:** ![mark\_vieira](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/mark_vieira/32/5396_2.png) [@mark\_vieira](https://discuss.gradle.org/u/mark_vieira)\ **Post date:** [February 20, 2016, 12:17am UTC](https://discuss.gradle.org/t/2-8-2-9-mavendeployer-doesnt-honour-uniqueversion-false-in-maven-uploadarchives/13370/6 "2016-02-20T00:17:57Z")
> [@rockympls](#): > > My thinking is that maven-metadata.xml is being generated incorrectly. This is correct. This is mainly a result of our upgrade to using Maven 3 libraries internally where support for this feature has been dropped. This is an open issue and there have been other discussions on possible ways to fix this. Unfortunately there is no workaround. > [@Maven-metadata.xml created for non-unique SNAPSHOT artifacts](https://discuss.gradle.org/t/maven-metadata-xml-created-for-non-unique-snapshot-artifacts/13938): > > When unique versions are disabled via the [MavenDeployer#setUniqueVersion(boolean)](https://docs.gradle.org/current/javadoc/org/gradle/api/artifacts/maven/MavenDeployer.html#setUniqueVersion(boolean)) method, a maven-metadata.xml file is still created which later causes problems with resolution when Gradle reads the metadata and then tries to incorrectly search for an artifact with a unique version name. A problem occurred configuring root project ‘TextWrapping’. Could not resolve all dependencies for configuration ‘:\_debugCompile’. Could not find com.android.support:support-v4:23.0.0-SNAPSHOT. Searched in … ---
**Author:** ![daz](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/daz/32/2475_2.png) [@daz](https://discuss.gradle.org/u/daz)\ **Post date:** [February 21, 2016, 5:03pm UTC](https://discuss.gradle.org/t/2-8-2-9-mavendeployer-doesnt-honour-uniqueversion-false-in-maven-uploadarchives/13370/7 "2016-02-21T17:03:14Z")
I’ve created GRADLE-3405 for this issue. ---
**Author:** ![randy-motluck](https://avatars.discourse-cdn.com/v4/letter/r/e9bcb4/32.png) [@randy-motluck](https://discuss.gradle.org/u/randy-motluck)\ **Post date:** [July 15, 2016, 6:16pm UTC](https://discuss.gradle.org/t/2-8-2-9-mavendeployer-doesnt-honour-uniqueversion-false-in-maven-uploadarchives/13370/8 "2016-07-15T18:16:03Z")
Hi all. This fixed my issue that I believe is similar to the ones above. The problem I see is that each publication in the publishing config gets a new timestamp for the upload. I am using Spring Boot and its plugin as well. So by adding the extra artifacts ( from the Jar tasks) to the one publication, it worked. All items have the same timestamp that matches and the metadata.xml file appears to work such that a dependent project can now access the api objects. See this example: ``` task apiJar(type: Jar) { classifier = 'api' from(sourceSets.main.output) { include "com/company/app/dto/**" } } task sourceJar(type: Jar, dependsOn: classes) { classifier = 'sources' from sourceSets.main.allSource } task apiSourceJar(type: Jar, dependsOn: classes) { classifier = 'api-sources' from(sourceSets.main.allSource) { include "com/company/app/dto/**" } } publishing { publications { mavenJava(MavenPublication) { from components.java pom.withXml { asNode().appendNode('description', 'APP Sprint Boot App') } artifact apiJar artifact sourceJar artifact apiSourceJar } } repositories { maven { credentials { username = 'username' password = 'password' } if(project.version.endsWith('-SNAPSHOT')) { url "http://server:9081/artifactory/libs-snapshot-local" } else { url "http://server:9081/artifactory/libs-release-local" } } } } ``` ---
**Author:** ![Warren](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/warren/32/7063_2.png) [@Warren](https://discuss.gradle.org/u/Warren)\ **Post date:** [July 16, 2016, 1:09am UTC](https://discuss.gradle.org/t/2-8-2-9-mavendeployer-doesnt-honour-uniqueversion-false-in-maven-uploadarchives/13370/9 "2016-07-16T01:09:30Z")
I may be wrong but I don’t think this is the same problem. The issue is that with the underlying Maven 2 framework when using uniqueVersion is false there are no timestamps at all, so every -SNAPSHOT build simply overwrites the previous version. The consuming project simply requests the snapshot version without any further qualifiers (date, latest, etc). With Maven 3 now it always generates timestamps so any consuming builds don’t work as they can’t find the unqualified snapshot anymore.