When I run mvn versions:display-dependency-updates at home, I get the expected results (output that shows which dependencies have new version). However, when I run it at work, which uses an internal Maven repository (Nexus Repository Manager 2.14.13-01), the results always shows "No dependencies in Dependencies have newer versions."
However, if I go in through the web interface, I can see that there are newer versions in the repository. I am guessing that they set something up incorrectly, and would appreciate any information that I can provide them to help get this resolved.
Here is the output using the verbose option:
[INFO] --- versions-maven-plugin:2.8.1:display-dependency-updates (default-cli) @ TestProgram) ---
[INFO] The following dependencies in Dependencies are using the newest version:
[INFO] commons-beanutils:commons-beanutils ............................ 1.9.1
[INFO] org.apache.commons:commons-collections4 .......................... 4.0
[INFO] org.apache.commons:commons-compress ............................. 1.15
[INFO]
[INFO] No dependencies in Dependencies have newer versions.
Odds are you work cloned Maven Central, the repository where most Maven items are stored. In this clone, they took a snapshot of what they were using. Typically this is done with Artifactory mirroring.
Basically the local Artifactory gets the request, and then it re-makes the request to Maven Central, caching a local copy. The next time a request is made for the same item, it is served from within the company's servers.
What appears to have happened is that an organizational change, a configuration change, or simply a connection to the Internet change has broken the relay ask to Maven Central, and now all of your requests for the latest items only show the latest items in your company's Maven Central Mirror.
Some companies have legal teams that have joined the mix, so they don't approve pulling new software (or even new versions of used software) without a review of the software's license. This reduces the legal risk of a developer including licensed software that could force the company to expose their code, or that might require paid licenses. In such companies, they only turn on the mirroring for a single download, documenting the dependencies, and reviewing all the downloaded software licensing.
As you can imagine, a legal team is happy to recommend this process; but, is not typically on the time table of a development team. I've updated such software stacks, and it generally takes between one and two months to get all of the licenses approved (most of it getting through to the correct legal representative, who will likely read the Mozilla Public License for each product to maximize billing time).