It is no news that having a corporate
POM for a group of projects is a
maven best practice for standardization purposes and avoiding repetition.
And just like any other project a parent POM is also a living project and you need to update it from time to time. When the parent POM is updated, you also need to make the inheriting projects receive this update. There are two ways to do this;
- We can either perform releases and have the version increased
- Or we can deploy it without making a release (no version increase)
At first the second option seems logical since it does not require any communication to inform the users of this POM to upgrade the version. Actually it does. When you make a deploy without a release, there is no way to be sure that the developers will have the latest POM on their local, maven will not download it from the repository because there is already the copy in the local repository with the same version.
There is a long thread discussing these two approaches. As stated by someone on this thread that the problem is actually the same, either way you need to communicate the update with the developers. The only difference is the content of the dispatch 🙂
- For the first approach, you have to tell the developers to upgrade the version of their parent POM to the latest one. (send an email)
- For the second approach, you have to tell the developers to delete their local copy of the parent POM from their local repository. (send an email)
In the end the problem seems to be how to communicate. Sending an email is not a good option, it can get lost, go to junk or simply can be ignored. We need a persistent and controlled way to communicate this. We can simply make the maven build let the developers know that there is an update, we can even make the build fail if it is needed.
What the simply plugin does is;
- Checks whether the current building project has a parent POM
- If so checks whether it is one the parent POMs that we want to check for updates
- If so checks whether there is a newer version
- If so depending on the plugin configuration, it makes the build fail or print a warning to let the developer be aware of it
In order to activate the plugin all you have to do is to configure it within your parent POM. See the following snippet for the configuration options.
The plugin attaches itself to
validate lifecycle phase if the user does not explicitly specify an
At first sight making the build fail when there is a parent POM update seems annoying from the developer perspective however there are sometimes that you want to ensure that the version is upgraded by all the using projects. But with the configuration above you cannot do that, you cannot change your config to force the upgrade because this config is already in your parent POM, meaning; in order to force you need the using projects to upgrade the version. It is a chicken-and-eggs problem.
There is another option to make a SPECIFIC VERSION of your parent POM to force the update. You can define the very same property
force.upgrade as a property in your parent POM just before release. Besides just checking plugin’s configuration for
forceUpgrade, the plugin also searches
force.upgrade property within the available parent POM to see if there is a SPECIFIC VERSION that forces for upgrade. And if it finds a version forcing for upgrade, it will make the build fail not matter what the plugin’s
forceUpgrade config is. See the following example config.
See the following sample build outputs depending on the situation.
When the plugin is configured with
force.update=false and there are two new versions, it just displays a warning log.
When the plugin is configured with
force.update=true and there are two new versions, it makes the build fail.
When there are three versions one of which is forced (meaning there is a property
force.upgrade=true within the released parent POM, it makes the build fail even the
forceUpgrade is false for the plugin.
I will also try to put it on maven central repo.