0

Consider a project that is used in other projects, and this project has version 1.0 and is present in the Nexus.

After that, some changes are done in this project. Now there are two solutions:

  1. Increment the version of the project to 2.0, and delete the version 1.0 from Nexus. When the developers try to get the dependencies from the Nexus with version 1.0 they will get an error that this version does not exist and need to change the version to 2.0.

  2. Change the functionalities of this project and inform the crew that some changes are done, but this is not the practice at all.

Is there any functionality in Maven and Nexus to simplify this task and make this all happen in the backend so the developers can't do anything, or is this not possible?

rohanagarwal
  • 771
  • 9
  • 30
Youcef LAIDANI
  • 55,661
  • 15
  • 90
  • 140
  • Why do you want to remove 1.0? The purpose of versioning is to disallow changing things in a released product. Suppose you could, two developers could not even rest assured that using the same library in the same version are running exactly the same code. – Tunaki Jan 29 '17 at 14:11
  • ok @Tunaki, consider i don't remove the version and i makes some changes, how the developers know about this changes ? what i know if the developer download a jar from nexus the first time it store in the `.m2` folder then he use this jar with this functionalities so if i change the functionalities in and re-install this jar, the developer still work with the old functionalities, because he use the jar from the .m2 and not from the nexus server, and because maven not change the jar because it is always exist with the same **GAV**! i think this is the policy of maven i'm wrong? – Youcef LAIDANI Jan 29 '17 at 14:31
  • Stability is the key word here. If someone is using version 1.0, their build has to keep working. Maybe 1.0 is buggy, but it is no reason to remove it entirely. I assume the project is documented, has a website, etc... Show the latest version there, send mails, communicate. – Tunaki Jan 29 '17 at 14:34
  • yes, i'm with you @Tunaki, i want just to facilitate this task that's all, so what is the solution, or it still the old way inform them with a messages :(, i think maven can do better then this, what you suggest to me – Youcef LAIDANI Jan 29 '17 at 14:39
  • Well if the website is published with Maven, the latest version is already shown. You can also look at the [Changes Plugin](https://maven.apache.org/plugins/maven-changes-plugin/) to send announcements. – Tunaki Jan 29 '17 at 14:42
  • thank you @Tunaki, i think for dependency management, so can this way help me in this case, i mean suppose i will create a parent pom in nexus then all the developers can use this pom as a part of them project, so if i want to change i will change only in this parent pom, but i can't arrieve to this solution i already asked a question similar but it is closed by you http://stackoverflow.com/questions/41919702/create-a-jar-that-contain-dependency-management-maven i hope you get my point, thank you for your help – Youcef LAIDANI Jan 29 '17 at 14:46
  • 3
    Maven isn't a replacement for communication between developers. This was never, never the intention in the history of maven. If you deploy a new version to nexus, you have to inform developers who depend on this project. There are several ways to do this. – JimHawkins Jan 29 '17 at 22:18
  • If you create a parent Pom and add dependencies there, you have to update the parent poms version if you update the versions of the dependencies... – JimHawkins Jan 29 '17 at 22:26
  • As a side note: We established a company-wide blacklist of artifacts that is contacted in every Maven build. This allows us to forbid the usage of a given GAV, if this would be dangerous or just does not make sense anymore. – J Fabian Meier Aug 21 '17 at 13:50
  • thank you @JFMeier – Youcef LAIDANI Aug 21 '17 at 13:51

1 Answers1

2

If you have an old version of an artifact that must not be used anymore because it has some dangerous bug, or it does not work with the new database structure or something like this, it may be advisable to move it to some non-public Nexus repository (and also delete it from the local repository of the build server), so that nobody can use it for release builds (people can use it for local builds, but this is usually not dangerous).

If you want to manage standard versions throughout your company, it is a good idea to have a parent pom or some boms which collect versions in a <dependenyManagment> section and can be included by the developers. This way, you only need to inform them to change one version number (namely the one of the parent pom or bom) instead of many.

Still, you are left with the problem that people do not read company newsletters. I know the problem that many developers of jars compile and test their source code against very old versions of their dependencies while the war/ear (that includes the jar) uses new versions.

J Fabian Meier
  • 33,516
  • 10
  • 64
  • 142