Redirect warning when publishing to empty maven repository about gradle

[adammurdoch]

I'm pretty sure that warning is produced by aether. Gradle uses this in MavenDeployAction and MavenInstallAction to do the work of publishing a maven module.

[06needhamt]

I am interested on working on this issue however i am unsure on how to locate the code in question. Is there any documentation for the directory structure of Gradle?

[eriwen]

@06needhamt Wonderful! Locating it is the toughest part. I would suggest looking for places where we try to resolve maven-metadata.xml. subproject/dependency-management is one place. It's possible you may need to navigate from there to code in core or publish to see where the logging is called.

Hope that helps!

[eriwen]

Hi @06needhamt. Any update on this? Need any other guidance?

[alsutton]

The problem is triggered by the call in MavenDeployAction, which is a call through to Aether. During the handling of that call the code to merge the new artefact into the existing repository information triggers an attempt to get the existing maven-metadata.xml which occurs on a background thread.

The call goes through to the wagon file provider and triggers an exception, which is, of course, the most common way of propagating a file not found issue in Java. Unfortunately Aether treats all exceptions in this situation in the same way, so this gets propagated back to Gradle using a generic "Something has gone wrong" mechanism.

So there are multiple components involved, but there seems to be only one way that this could be realistically fixed, but that involves hacking some logic into Gradle to detect this error and silently drop it (which should be behind a config option to avoid breaking backwards compatibility).

The reason modifying Aether isn't feasible is because it seems to be abandonware :(. The sonartype repo points to eclipse, and the eclipse page is a redirect to their archived project list.

So what do people think? Is hacky logic what people want or are there other options people think might work?

[alsutton]

It looks like the Maven project have switched to a different library This could be an option if someone has the time.

[eriwen]

@alsutton Thank you for the thorough investigation. Introducing hacks to silently drop specific exceptions is something we try to avoid, so switching to a different library is an option.

I'd wager this wouldn't quite make it to the top of our priority queue for some time, so I'd love to see a PR for this.

[alsutton]

I've not had time to see this through, and this probably won't change in the future, so I'm going to write up what I've found so far in case anyone wants to pick this up.

The version of Aether current being pulled in is an old version by Sonatype, the project moved from Sonatype to Eclipse where a couple more releases were made, then the project was archived. Version 3.3 of maven was using the Eclipse version of Aether, 3.5 has moved to the new library.

Unfortunately moving from the Sonatype version of Aether to the Eclipse version isn't a straight drop-in replacement;

• The package namespace has been changed to reflect the Eclipse home.
• There are a few API changes which need manual changes
• Gradle then fails to compile with the changes indicating there's more work to be done under the hood.

I've got my work so far up on my GitHub fork, if anyone wants to pick it up please feel free.

[eriwen]

@alsutton thanks again for the additional information; I hope others will be able to take what you've done and get this solved. 👏

[oehme]

@ldaley Was this also fixed by 92e1617#diff-afed11c0a1872ed31be4dfe32ed9bb23?

[bigdaz]

This has been fixed #9445