> Finally I opened app2-0.0.1-SNAPSHOT.jar and looked for the included app1-0.0.1-SNAPSHOT.jar file.
What does this mean? On Sat, 24 Sept 2022 at 00:05, Bruno Melloni <b...@melloni.com> wrote: > First, you are right... I misread. When I look at the maven plugins in > pluginManagement I see v2 and v3: clean=3.1.0, compiler=3.8.1, > surefire=2.22.1, jar=3.0.2, install=2.5.2, deploy=2.8.2, site=3.7.1, > project-info-reports=3.0.0. Still, it is > 2.0 so LATEST is no longer > supported as a version tag. > > Let's see if I can explain it better: > > - I emptied the local maven repository of every single one of my > projects, literally went in the folder net/myorg and deleted everything > from there. > > - Then I rebuilt in order. This included app1 and app2 (that has app1 > as one of its dependencies) which showed up in the local repository > folder. Obviously, both generated snapshot jars had a timestamp of > yesterday. > > - Finally I opened app2-0.0.1-SNAPSHOT.jar and looked for the included > app1-0.0.1-SNAPSHOT.jar file. I expected to see yesterday's timestamp > on the JAR file since I had just done a maven clean install. Nope, it > had a January timestamp, and the contents were old. > > So, it is clear that: > > (1) IntelliJ is caching the JARs it uses for a project somewhere. And > giving it the commands to reload dependencies or the POM fail if the > version number has not changed... since I am seeing a file from > January. Also, the IntelliJ setting "Always update snapshots" fails as > well. This may be an Maven issue or it might be a quirk of IntelliJ, my > suspicion is that IntelliJ relied on the old 2.x maven behavior for that > setting. Sadly I am not knowledgeable enough to know. > > (2) Looking for an alternative all I found for 3.0 and above Maven was > the use of version ranges in the dependency entry of the app2 POM. That > would require updating the version after even a tiny change in app1, but > at least it would not require updating the version in the the pom of the > myriad of "app2"s that we have, unless we wanted to. I suspect this is > what versions-maven-plugin does but that I botched it when I tried to > use it, as its documentation is very confusing for a beginner and they > don't provide a single complete example of a POM that uses it. The > symptom was an error popping up in the POM itself, long before trying to > do a build. I think the error was either the "<version>[0.0.1, > 0.0.999)-SNAPSHOT</version>" tag, or my missing something in plugin > management. > > Conclusion: > > It seems that the cleanest way to solve this is to use the > versions-maven-plugin, but I am not using it right. Any help on this > would be great. A simple working example of a POM that uses > version-maven-plugin with a version range would be ideal. > > > On 9/23/2022 1:25 PM, Nils Breunese wrote: > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
