I just sync'd an artifact to Maven Central from oss.sonatype.org. Immediately after doing so, a problem was discovered (of course). I haven't announced the new artifact yet, it is very unlikely that anyone is using it yet, so I'd like to take it down before anyone starts using the broken version.
How can I remove a broken artifact from Maven Central?
Can't be done. It's A Rule. But if you want to try, contact the Sonatype people who support oss.sonatype.org. So you generally push a new, higher, version with the fix, and tell everyone to use it.
If you accidentally distributed an artifact which does not work or has bug or whatever the usual solution in Maven is to create a new version which fixes the problems. That's it. Deleting in Maven Central is not be done and shouldn't ever happen.
You can't remove an artifact from Maven Central because others might have used it already. Maven will not check for updates for non-snapshot versions of artifacts, so if someone has used the old version and a new version was uploaded, those people would never see the new version.
The workaround is to release a new version of your artifact.
It's hard to resist the urge to just release the staged repository (it's only a click away), but as suggested in the Sonatype OSS Usage Guide
You will want to download them and do some manual testing (or hold a
community vote) before finally releasing them.
If it's the first time you've released, then you'll have to comment on your OSS Sonatype JIRA ticket to get Central synch activated. Presumably this is an opportunity to say "Wait! This artifact is broken. Please please please don't synch it to Maven Central!" :)
But as others have said, if it's released then it's too late - you'll have to release a new version (and ensure your users are aware not to use the broken one).
Beta releases are a good idea for new/major releases - people are a bit more forgiving if you've stuffed something up, and you don't lose your desired version number.
If you don't want to create a new version, another solution would be to push the fixed artifact under the same version.
Related
The Byteman website advertises version 4.0.11 as released: https://byteman.jboss.org/downloads.html
But only some artifact IDs are available on Maven Central: https://search.maven.org/search?q=g:org.jboss.byteman
Did something go wrong during the release? Did artifact IDs change?
Thanks for reporting this. There was no problem reported during the maven build or upload to the Sonatype repo and my release of the artefacts was indicated as successful. However, Sonatype has been rather flaky recently. It seems to have lost many of the artefacts at release (before transfer to Maven Central).
I have hand uploaded all the missing artefacts for 4.0.11 to Sonatype and checked that they are all currently resident in their repo. I also checked and the 3.0.18 artefacts (originally released at the same time) also seem to be present on their site. These all ought to get pushed over to Maven Central soon. If that doesn't happen within a day or two (worst case) then that probably means the Sonatype copying operation is wedged again. Let me know if so and I will raise the transfer problem with them. Let's keep our finger crossed they don't lose the uploads.
We are using Maven as build manager and Nexus as our artifact repository.
From time to time we are having this dependency problem and Maven is not able to find the artifact in Nexus by a slight difference in the snapshot version number. In this case, the difference seems to be 1 second.
Currently, a build is failing, maven is looking for
SOME_ARTIFACT-0.0.1-20181217.115318-337.jar
but on the Nexus we have
SOME_ARTIFACT-0.0.1-20181217.115317-337.jar
This is not happening all the time, but from time to time I see this problem, and in order to solve this I need to redeploy SOME_ARTIFACT before building the application that depends on SOME_ARTIFACT.
Do you have any idea why this is happening? I know I can use release versions and totally avoid this snapshot issue but this SOME_ARTIFACT is under constant update and development, so I don't wanna keep releasing, plus, what I want is to figure out the reason behind this problem not to basically avoid it.
Maven version: 3.5.0
NEXUS version: OSS 3.12.1-01
Any help is appreciated.
Thanks!
Thanks for providing the Maven version. Likely you are being impacted by https://issues.apache.org/jira/browse/MNG-6240. Update Maven (or downgrade to 3.3.9) and that should help.
I recently encountered a difficulty to find back a transitively dependent Maven artifact when building our product, which triggered me to think what is the correct strategy to deal with the situation.
In my product building CI, I need to use a plugin called Maven-Unix-Plugin, which is visible to us. This plugin transitively depends on function-java, which is not visible to us.
We have a Nexus repo, which proxy to the Maven repo. So, in the ideal situation, we don't need to store either maven-unix-plugin or functional-java.
However, I found the expected version of maven-unix-plugin still exists in Maven repository, but its dependent version of functional-java disappeared! More ironically, for all versions of maven-unix-plugin, whose dependent version of functional-java disappeared! In short, the maven-unix-plugin is not usable anymore!
In simple, this sounds an integrity problem of Maven repository. However, my major thinking is how we can avoid this on our side? Now, I managed to find back the old versioned functional-java and put it in our Nexus. However, first of first, it is impossible for us to figure out all of the transitive dependents and put all of them in our Nexus. The ideal picture of Maven is we should NOT be required to do that!
Of course, if we continuously build and maintain our system (and keep updating the dependency version ideally), we should have not faced this problem. However, we are a very small team to maintain a long list of huge legacy systems. The last build for this product is actually 2 years ago!
Any brilliant insights what is good strategies for this kind of headaches to happen in the future?
First of all, MavenCentral very rarely removes artifacts, and only if absolutely necessary. So this problem is likely not to hit you again.
If you want to make sure that this problem will not come again, make sure that you backup the storage of your Nexus repo. All artifacts that are drawn from MavenCentral through your Nexus will be stored in your Nexus storage. So even if MavenCentral is completely wiped out tomorrow, they will still exist in your Nexus.
An old legacy project in my team is being salvaged for any usable part, one of its dependency is play-json_2.10 with a version number 2.2. However since its too old, its missing from all the major repository, including typesafe and sonatype central. The only place i can find it is on github:
https://github.com/mandubian/play-json-alone
I could download it and manually save it to a local maven repo but my team mate won't be able to see it after checking out my commit. Is there a way to make maven downloading from github and put source code somewhere? Thanks a lot.
I'm not new to maven. but I don't know why my maven use 1.1.1 version of maven-plugin, hornet-maven-plugin. the reason I say about the version is that the repository doesn't have the version. So I think I have to change the version of plugin that the repository has.
the soure code is here( https://github.com/verystrongjoe/hornetq/tree/master/examples/jms/clustered-queue ).
I downloaded that to my local disk. and I imported to my eclipse.
but the result was an error like below.
Failure to find org.hornetq:hornetq-maven-plugin:pom:1.1.1-SNAPSHOT in http://repository.jboss.org/nexus/content/groups/public was cached in the local
repository, resolution will not be reattempted until the update interval of jboss-public-repository-group has elapsed or updates are forced
If you go to the repository http://repository.jboss.org/nexus/content/groups/public , there are 1.1.0 or 1.0.0.
please let me explain about this.. thanks in adavance.
You can see the answer on Line 716 of the super-POM:
<plugin>
<groupId>org.hornetq</groupId>
<artifactId>hornetq-maven-plugin</artifactId>
<version>1.1.1-SNAPSHOT</version>
</plugin>
It sounds like you might not be knowledgeable enough to work on the edge of the github source. Perhaps you should work with one of the recent release tags instead?
You are forking and trying to work with an in-development SNAPSHOT version of HornetQ. That normally requires more work than using released versions. Tip one: consider working only with released versions of HQ.
If not, be aware that:
HornetQ does not release *-SNAPSHOT versions of artifacts to Maven repositories. That is the reason you won't find them at that JBoss Maven repository. BTW, See here for comments with regards to figuring out dependencies of HornetQ examples https://github.com/hornetq/hornetq#recreating-the-examples
See here about the minimal instructions of using the SNAPSHOT version of the hornetq-maven-plugin https://github.com/hornetq/maven-hornetq-plugin/blob/master/README.md
Please notice that the content of each of those links is small. I could have copied their content here but I didn't. My point is: these projects have README files which address your issues, you should always check the README.