I thought this would be pretty trivial to fix so I gave it a try.

Unfortunately, org.apache.maven.artifact.ant.DeployTask (the base class of org.gradle.api.publication.maven.internal.ant.CustomDeployTask) does not expose updateReleaseInfo either.

AbstractDeployMojo is the class that defines the updateReleaseInfo attribute of the maven-deploy-plugin.
DeployMojo sets the value of updateReleaseInfo on created DeployRequest instances.

Those are used to call DeployMojo.deployProject(DeployRequest) which executes the following code:

if ( request.isUpdateReleaseInfo() )
{
	artifact.setRelease( true );
}

before calling AbstractDeployMojo.deploy with Artifact artifact as argument which is in turn calling deploy on ArtifactDeployer.

DefaultArtifactDeployer calls RepositoryUtils toArtifact which is ignoring isRelease.

It also creates another DeployRequest and a RepositorySystemSession

RepositorySystemSession session =
	LegacyLocalRepositoryManager.overlay( localRepository, legacySupport.getRepositorySession(), repoSystem );

which is later used to call deploy on the repoSystem

DeployResult result;
try
{
	result = repoSystem.deploy( session, request );
}
catch ( DeploymentException e )
{
	throw new ArtifactDeploymentException( e.getMessage(), e );
}

Some metadata juggling is also performed in this method but the original artifact isn't used anymore, only the one that was freshly created by RepositoryUtils.

I kind of lost the motivation to dig deeper at this point... but I wanted to dump this info anyway since it may serve as a shortcut for the poor soul that gives this a shot in the future.

Thanks for the info Joern.

Hi,

Is there any progress on this particular issue ?
This is a bit annoying for users who rely on "latest" symbolic versionning for Continuous Integration / Delivry

Regards,

No progress at this time.

It is being considered for the 2.5 release.

Thanks for the update Luke, is there a work around to set updateReleaseInfo to true for the time being? Is the option available in the latest nightly by chance?

I'm also with problems to reload my Nexus maven-metadata.xml after the mavenDeployer with gradle. Any workaround until the 2.5 release?

This didn't make 2.5, but it's still on our list. There's no workaround known at this time unfortunately. If you're interested in expediting the fix, please email the https://groups.google.com/forum/#!forum/gradle-dev list and we can provide some guidance on what needs to be changed.

Hi Luke Daley !

Is there any news regarding this issue (missing update to 'release' attribute in maven-metadata.xml) ?
This is an annoying issue : it prevents us from having simple Continuous Delivery pipeline...

Best regards,

I believe this actually was fixed in Gradle 2.5 as a result of this change. Using Gradle 2.5 or later seems to add the <release> tag to maven-metadata.xml when using both the 'maven' and 'maven-publish' plugins. Have you tried this again with a more recent version?

Hi Mark Vieira !

I've just performed a new test with Gradle 2.9 and you are right : <release> tag of maven-metadata.xml is updated but not <latest> tag.

As you can see below, <latest> tag is still an old version whereas <release> tag is updated :

<metadata>
   <groupId>XXX</groupId>
   <artifactId>YYY</artifactId>
   <versioning>
       <latest>1.0.967</latest>
       <release>1.0.968</release>
       <versions>
         <version>1.0.315</version>
[...]

I think this can cause some unexpected behavior of Nexus and other CI tools.
Could you please have a look ?

Regards,

Doing some research it seems <latest> is only used by Maven when resolving plugins, therefor it is only updated when publishing a plugin. General consensus is using <latest> for anything is bad practice. That said, Artifactory seems to keep this up to date, however Nexus does not. It doesn't seem that the Maven APIs even expose a way to influence adding this to the Metadata.

This won't cause any issues with Nexus or CI. They don't look at any of this information and neither do consuming projects.

Since strictly speaking this issue has been resolve (as it has nothing to do with <latest> I'm marking this resolved in Gradle 2.5.

Actually the <latest> is used by Nexus when requesting the 'latest' version of any package.

See for example :
https://oss.sonatype.org/nexus-restlet1x-plugin/default/docs/path__artifact_maven_content.html
https://oss.sonatype.org/nexus-restlet1x-plugin/default/docs/path__artifact_maven_redirect.html
https://oss.sonatype.org/nexus-restlet1x-plugin/default/docs/path__artifact_maven_resolve.html

Do we really need to create another issue to ask Gradle to update that <latest> field too ?

I've created an issue for this: https://issues.gradle.org/browse/GRADLE-3384.

That said, I'm still not convinced that we should be populating this field as Maven only sets this when publishing a Maven plugin. If Nexus is using this information for other purposes, or relying on it existence for non plugin artifacts, that seems incorrect.

Olivier, are you certain the Nexus API strictly relies on <latest>? Nothing in those links makes me think that is the case. This information could just as well be inferred from <versions>.