A version conflict arises if there are two or more dependees in the dependency graph that depend on different versions of the same artifact. Deputy automatically resolves such conflicts using the rules configured.
You can ...
To do so, expand the conflicts node of the top level project after applying the rules. For each node where there was a conflict to resolve there is a sub node naming the respective artifact. Below that you find all the versions Deputy had to choose one from. The one that was chosen is highlighted in green whereas all rejected versions are coloured white. Digging deeper, you can expand the 'used by' node of each candidate to see which dependees depend on which version according to their POMs.
If you don't agree with any of the choices Deputy made, change the rules and re-apply them.
Each conflict group is classified as to the suspected severity of the conflict and displayed accordingly under one of the three icons for 'info', 'warning' or 'error'. The classification is only meant to be a helping hint and is by no means an undisputable judgement.
It works quite fine if the artifact is strictly versioned according to the Sun Versioning Scheme: major.minor.micro
Major version numbers identify significant functional changes (which are usually not downwards compatible).
Minor version numbers identify smaller extensions to the functionality (which are usually still downwards compatible).
Micro versions are even finer grained versions (which are always downwards compatible).
If the conflict is one between micro versions only, the impact classification is 'info'.
If the conflict is one between minor versions but all major versions are the same, the impact classification is 'warning'.
If the conflict is one between major versions, the impact classification is 'error'.
If there are versions that deviate from the simple major.minor.micro scheme, Deputy is not able to interpret their meaning and guesses the 'warning' impact as the happy medium.