Hi Bruno,

It’s not completely clear to me what your issue is exactly. Is ’the old cached 
version from January’ that you refer to an artifact with a snapshot version or 
a release version? If it is a snapshot version, it depends on the update policy 
whether Maven will use a locally cached snapshot or whether it will try to 
fetch an update from the the configured repository. If there is no explicit 
update policy configured, I believe the default is to look for updates once a 
day. You can force Maven to update snapshots by using the -U (or 
--update-snapshots) flag. If your dependency is a release version, then there 
can be only one artifact for that version and if you have it cached locally, it 
should be identical to that version of the artifact on the repository server.

Maven 4 has not been released yet, are you sure you are (and should be) using 
that version? Version 3.8.6 is the current latest release [0].

To avoid having to manually update dependencies my team has a scheduled task to 
run Renovate [1] in our applications' CI pipelines to check for dependency 
updates. Renovate automatically creates a branch and a merge request whenever a 
dependency update is found. There are more tools like Renovate. For instance 
GitHub also provides Dependabot [2]. Maven Versions Plugin [3] can also be used 
to update dependencies.

Nils.

[0] https://maven.apache.org/download.cgi
[1] https://github.com/renovatebot/renovate
[2] https://docs.github.com/en/code-security/dependabot
[3] https://www.mojohaus.org/versions-maven-plugin/

> Op 23 sep. 2022, om 14:58 heeft Bruno <x.ma...@melloni.com> het volgende 
> geschreven:
> 
> I apologize for the length of this email, I could not think of a shorter way 
> to present the issue/questions that is clear enough.
> 
> ---
> 
> My environment involves the usual many open source dependencies (which I 
> control by specifying the versions to use in a master POM), but also a large 
> number of frequently changing internally built dependencies and a huge number 
> of applications that rely on these dependencies.
> 
> Changes on these internally built dependencies are carefully controlled so 
> that they are always backwards compatible.  In over a decade before we used 
> maven we had a single instance of these dependencies and we never - not once 
> - had a version conflict problem.
> 
> But the default mode for Maven is to update the version number even for a 
> tiny change and then to manually update the version of the dependency in 
> every single project that depends on it.  Since we have a lot of those, this 
> is a horribly error prone process leading to applications that crash because 
> they are using the wrong version of a dependency.  As an example... one of 
> our crashing applications that was built yesterday was found to contain a 
> dependency JAR from January!!! when it should have contained a JAR that was 
> also built yesterday.
> 
> Things that we tried:
> 
> - Builds and executions *INSIDE* of IntelliJ work beautifully. It always 
> finds the latest code and it always runs on the local integrated server 
> perfectly. _The problem happens in the JARs/WARs of applications placed into 
> the Maven local repository_.
> 
> - In IntelliJ we tried checking 
> Settings/Build,Execution,Deployment/BuildTools/Maven/"Always update 
> snapshots" and not change the version number between releases so that it 
> would include a fresh copy of the dependency during build, but even 
> *completely wiping out* the local repository (the only one in use at this 
> moment) it still used the old cached version from January.
> 
> - Next I tried to use the <version>LATEST</version> syntax in the POM.  But 
> LATEST was removed after Maven 2 and we are using Maven 4.
> 
> - Finally I tried to use <version>[0.0.1, 0.0.999)-SNAPSHOT</version> in the 
> hope of simply updating the version number of the dependency during 
> development/tests and only updating the formal dependency version to 1.0.0 at 
> release time but Maven rejected the syntax.  It is quite possible that the 
> syntax I used is incorrect, but sadly the documentation is not very clear and 
> provides no complete examples that I could inspect or duplicate.
> 
> *QUESTIONS*:
> 
> 1) Was one of the above methods supposed to work?  If yes, what did I do 
> wrong and how do I fix it?
> 
> 2) If none of the above methods is supported anymore (Maven 4), what method 
> should I be using?
> 
> 3) Is there any other tool - besides Maven - that I should be using for these 
> builds.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reply via email to