Automatically force update pom to newer versions from inside a test

Question

This is not related to update the pom dependencies using a maven goal. I already have that sorted out. So I am responsible for creating, packaging and maintaining common utilities. These common utilities are in turn used by all the teams in the org. Problem is that the teams using these utilities do not update the dependencies unless it is the last resort. We would like them to use the latest release version of our common utilities barring very few. Now I have come across this Maven Versions Plugin by mojohaus which I think serves my need by using two goals - versions:update-properties and versions:use-latest-releases. It serves my purpose except two things:

1. I do not see a way to exclude certain groupid:artifactid from the update dependency/property

2. We really want this to be a compulsory thing (maybe part of the Test execution - this is for test automation utilities mainly) rather than a maven goal. Because if it is a maven goal, it needs to be invoked separately and hence becomes optional for teams.

We know that forcefully updating to latest version might cause some issues with defect re-produciblity, but we are willing to take that risk. Our utilities are really test products.

Any direction/help on this is appreciated.

Edit: We run our tests using maven goals clean install already. So they use existing pom. We want dependencies update to happen before the tests run. Also it is desirable to commit the changes to source control (bitbucket) if possible. We have our tests setup using Jenkins but teams also run multiple test on local machines.

Edit: Found the answer to #1. The plugin provides to exlude regex for group and artifact id. using tags excludes and excludesList

Answer 1

Sorry for insisting. From the Maven point of view I see two main solutions:

1. Your projects and your utility jar are tightly coupled and every project always needs to use the latest version. Then you can bundle all projects and your utility in one multi-module project. This makes sure that everything is up to date all the time, but it requires that all projects and your utilities are always build together (not separately).

2. You distribute your utilities to different projects which build and release at different times. Then it is up to the projects to decide when to update. There is unfortunately no standard way to deprecate jars.

If I understand you correctly, you want something "in the middle". This may be hard to achieve.