[GRADLE-3113] Maven uploading is not updating 'release' information in maven-metadata.xml Created: 26/Jun/14  Updated: 14/Jan/16  Resolved: 13/Jan/16

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: 2.5-rc-1

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Fixed Votes: 6


 Description   

See linked forum post.



 Comments   
Comment by Joern Huxhorn [ 15/Jul/14 ]

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.

Comment by Luke Daley [ 15/Jul/14 ]

Thanks for the info Joern.

Comment by Damien Raude-Morvan [ 08/Apr/15 ]

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,

Comment by Luke Daley [ 08/Apr/15 ]

No progress at this time.

It is being considered for the 2.5 release.

Comment by Josh Kasten [ 13/May/15 ]

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?

Comment by Dinis Nunes [ 24/Jun/15 ]

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

Comment by Luke Daley [ 24/Jun/15 ]

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.

Comment by Damien Raude-Morvan [ 06/Jan/16 ]

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,

Comment by Mark Vieira (Inactive) [ 06/Jan/16 ]

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?

Comment by Damien Raude-Morvan [ 08/Jan/16 ]

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,

Comment by Mark Vieira (Inactive) [ 08/Jan/16 ]

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.

Comment by Mark Vieira (Inactive) [ 13/Jan/16 ]

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.

Comment by Olivier Voortman [ 14/Jan/16 ]

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 ?

Comment by Mark Vieira (Inactive) [ 14/Jan/16 ]

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.

Comment by Mark Vieira (Inactive) [ 14/Jan/16 ]

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>.

Generated at Wed Jun 30 12:40:20 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.