Maven2 artifact was released more than once. Avoiding, detecting, fixing.

By neokrates, written on May 10, 2008


  • Join date: 11-30-99
  • Posts: 224
View Counter:
Rate it
  • What build management tool does your project or firm use?

    View Results

    Loading ... Loading ...
  • bodytext bodytext bodytext

You work with maven2 and some remote repository. Someone has released the Artifact twice or more times. The source was different on two or more occasions, but version is the same.

Why is it a problem?

Imagine that you just deployed the jar file MyVipPack.jar.

Many teams do depend on it. You have developed new methods/classes in new version.

What happened then you released the jar? You allowed that the new version of the jar can be used by other team members. You will surely want to integrate it in all projects, where your new code is expected.

You will do it by changing dependency:


and posting it in every pom and then in SCM (Subverion or CVS).

At that exact moment, all who checks out from repository will also expect and get your deployed MyVipPack-${NewVersionIJustCommited}.jar. No problems here.

💡 BUT. In 10 minutes after deployment you have encountered a huge problem, that you misspelled some Method Names, so other teams will have problems calling those methods. No big deal, you change it accordingly and deploy the MyVipPack-${NewVersionIJustCommited}.jar second time. For you locally, problem is solved. But you might have caused a problem for other developers…

What is the problem with deploying artifact with the same version twice?

Anybody who already has MyVipPack-${NewVersionIJustCommited}.jar will not get the new MyVipPack-${NewVersionIJustCommited}.jar!

To make things worse, nobody will even see why there code does not compile. In eclipse, for example, all missed new functions are marked as such, but why are they missing, all jars are in place!?

The experienced maven2 developer will know where to look and will backtrack the problem to jar you posted and tell you about that problem. After 30 min to 1 hour of work! For normal developer it might cause many hours time loss and then probably a conflict with you.

They will get under pressure because of this time loss; they will endanger the release, etc… And these two cases are really just a beginning. Your invalid version of the artifact might find its way into release to other team, project, firm. In that case it might cause even days of delay.

What are the signs of the problem?

Other then described consequences of the problem there are typical signs of this problem:

  • Maven will get all artifacts but compile errors are available;
  • Source is compatible. Code from SCM is fine, you don’t see why maven/eclipse/you IDE cant compile;
  • Version of jars which contains the package is correct, and developer who deployed it will possibly say “version is fine and i see no problem locally”.

How to solve it in small team?

  • Let all involved people or just build master know, what you think the problem is and that you are fixing it now;
  • Increment version of you package ${NewVersionIJustCommited}+1;
  • Deploy new version;
  • Update all pom.xml files of projects which do use you jar;
  • Commit the source into SCM;
  • Let all depending teams know that they should update the pom;

How to solve it in bigger team/enterprise?

Technically – the same way. The big difference is that you should rather assess who else is or might be involved and let them know.

Here is who it might be:

  • Build masters;
  • Release managers;
  • Team leads;

If you consider not telling anyone and just fixing it, there are “pros and cons” of doing so. If you are not discovered that is definitely pro. But, if you will be discovered after some time and considerable problems/afford of your co-workers or other teams, it might be pretty bad for you.

What may be a long term solution to the problem

  • Never commit same artifact with different code in it. It is wrong!
  • Or, use -SNAPSHOT mechanism and commit whatever you want whenever you want. (Works only during development).
  • If you use the Artifact Manager like Artifactory or Nexus, there is a policy there, to prohibit the deployment of the artifact with the same version more than once.

Done :-)

Be Sociable, Share!

LEARN MORE (amazon bookstore)


Be Sociable, Share!

Leave a Reply