Hi, Does yesterday dependency build on an other pc? Then it should be "deploy" to your company central repository (Artifactory, Nexus, ...) to be fetched from your pc.
Using version range and snapshot is not good idea. It's better to use snapshot only. If you want incremental version from you CI/CD, you should not use snapshot. Regards, Arnaud Le sam. 24 sept. 2022, 08:49, Delany <delany.middle...@gmail.com> a écrit : > > 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 > > > > >
