0

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.
Ruminator
  • 129
  • 3
  • 13

2 Answers2

0

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).

Edwin Buck
  • 69,361
  • 7
  • 100
  • 138
  • Companies which are risk adverse are happy to pay lawyers to read each copy of the license, instead of taking the risk on themselves directly. It slows down development and keeps bug fixes and new features from entering their product more quickly. Law firms are happy to provide this service, or recommend it to risk adverse companies. Eventually tons of money is spent to validate that yes, v1.2.1 of commons-cli can be used, when v1.1.0 was previously approved by the same firm (an example, I don't know the current versions). – Edwin Buck Feb 18 '21 at 14:31
  • Thanks. I am looking at what is available inside the company's Maven repository, though (I can put in any of the versions that are listed as a dependency and it works fine), and I purposefully used an older version in my pom.xml file to see if the versions check would work. – Ruminator Feb 18 '21 at 14:34
  • @Ruminator Well, if it sort of works but mostly fails, Maybe the disk for the local repo is full, and can't download the up to date dependencies. Maybe some other issue has happened. Count yourself lucky, because technical issues are easier to fix than getting legal issues resolved on a timeline. – Edwin Buck Feb 18 '21 at 14:36
0

Sorry for the delay in getting back to this...the final solution was to switch the M2 .settings URL to the repository to a non-https link for my company. Due to settings I cannot change, the call that is made to check for versions gets a HTTP DENIED error when using the https URL. Switching to a regular http URL was able to correct this until such time as the network team is able to correct it otherwise.

Ruminator
  • 129
  • 3
  • 13