Just to clarify, the "snapshot lock down technique" as explained here: https://www.mojohaus.org/versions/versions-maven-plugin/examples/lock-snapshots.html
It WORKS even today if dependency in question is one artifact. But, it USUALLY becomes impossible, if you depend on some multi module build. Where I extensively use this technique is exactly with Maven and Maven Resolver: I deploy "controlled" builds to ASF "snapshots" and then "lock it down" in other (usually PR), and enjoy the benefit of full CI coverage and all (ITs etc) while at same time as sure it is "my change" that is being tested on. Resolver 2.0.0 had quite some changes: * new modules (that started at buildNumber 1) * module renames (transport http -> apache), similarly as above, apache transport was 1, etc Hence, referencing "I want a resolver reactor build that I know exactly comes from this PR/branch/whatever" (for example from a PR) is impossible, as "lock down" as explained on versions plugin becomes impossible, as modules have different buildNumbers. In this case, I "adjusted" the buildNo (basically ALIGNED them) using MNG-8055 (mvn 3.9.7) [and other tricks before 3.9.7 was out], and then I knew (as ASF CI deployed) which buildNo I really want, and then created Maven PR with that _exact_ TS "locked down" snapshot version, and was sure CI tested my change and my change only. Thanks T On Fri, Jun 14, 2024 at 8:36 PM Tamás Cservenák <ta...@cservenak.net> wrote: > Howdy, > > If for example sake, we define "maven" as mvn CLI and "build end" as "user > got on console "BUILD SUCCESS/FAILED" output and CLI process exited, then > at that point, this change would cause ZERO difference for SUCCESS builds. > > Where difference WILL happen, is in case of FAILED builds: nothing will be > installed to local repo and nothing will be deployed to remote repo. Which > is usually what we want, in reality. > > Re install today: > Let's assume that your project first "morning build fails in the middle" > (at module N+1), hence the first N module ends up installed in your local > repo, but second M modules (of some multi module build that has N+M modules > in total) are not. When you want to build some other project, that depends > on this project, the installed N JARs will be used that were built now > (this morning) as they are "fresh", just installed, but other M will be > pulled from remote (as last you installed yesterday, before you left the > office). basically ending with JARs on classpath that may come even from > different commits (depending what remote JARs, etc). > > Re deploy today: > Similarly, if you have a multi module build (N+M modules) and you deploy > snapshots as today, and the build fails at module N+1 (CI or dev > workstation, does not matter), after fixing the thing, and redeploy, all is > seemingly ok. But what happens is that due the first failure, the first N > modules will have "build number" in their timestamped version +1 offset > from those last M modules (basically as first N modules were deployed > twice, while last M modules only once). Hence, if you would like to "lock > down" or address whole reactor artifacts built together with a given TS > snapshot number, you cannot. But the same happens in the following > scenario: you have a multi module build of N modules, but this morning you > add one new module, hence you have N+1 modules. And you (or CI) deploy. The > "new" module will have buildNumber 1 (as it was deployed the first time), > while all the others may have 50 or even 100. Again, you cannot address > (and be sure) you use all the artifacts that were built "together". > -SNAPSHOT versions are "moving targets", and kinda helps alleviate this, > but they still can suffer from spurious problems, like explained at the > beginning: if you depend on -SNAPSHOT version and your commit in question > introduced binary incompatibility between modules, your build may fail (as > -SNAPSHOT will use first N modules with change, but "older" pre-commit M > modules without change). Etc. > > In short: > - in case of SUCCESS builds, at the moment CLI exits, the user > experiences NO difference (everything is installed and/or deployed just > like before) > - in case of FAILED builds, the user can be sure no "partial" installs or > deploys happened. This case is less important, as we tend to "fix" the > failed builds anyway. Rinse and repeat. > > Thanks > T > > On Fri, Jun 14, 2024 at 8:04 PM Maarten Mulders <mthmuld...@apache.org> > wrote: > >> Would flipping the defaults make this a backward incompatible change? If >> users are not aware of this change, it will change their build/deploy in >> a significant way... >> >> >> Maarten >> >> On 14/06/2024 19:49, Tamás Cservenák wrote: >> > Howdy >> > >> > Yes, Martin is right: am talking about the two plugin *AtEnd parameters, >> > and only about flipping their defaults. >> > >> > T >> > >> > On Fri, Jun 14, 2024, 18:29 Gary Gregory <garydgreg...@gmail.com> >> wrote: >> > >> >> Hi all, >> >> >> >> Install by default locally is probably OK for devs, especially for >> >> multi-module projects, but deploy by default is a bad IMO: I often >> work in >> >> one repo and install, then switch to another repo and test the new >> snapshot >> >> jars. Round and round until my changes are fully baked. This usually >> means >> >> having 2 Eclipse instances open at the same time, we have some projects >> >> with lots of modules. Deploying by default adds time and inflicts my >> work >> >> in progress on everyone else. I'm sure I'd turn that off. >> >> >> >> I would turn off both for sure in GitHub CI builds, so hopefully that >> can >> >> be turned off on the command line so I don't have to make my POMs even >> more >> >> complicated ;-) >> >> >> >> An otherwise happy Maven user giving up >> >> 2c, >> >> Gary >> >> >> >> On Fri, Jun 14, 2024, 12:15 PM Tamás Cservenák <ta...@cservenak.net> >> >> wrote: >> >> >> >>> Howdy, >> >>> >> >>> As history proved, the original "interleaved" install/deploy is just >> call >> >>> for problems, and causes in need for circumventions like >> >>> https://issues.apache.org/jira/browse/MNG-8054 to make classic >> "snapshot >> >>> TS >> >>> lock-down" possible on large(r) projects. Also, no wonder our users >> were >> >>> asking for this feature for a quite long time. >> >>> >> >>> Hence, I'd propose that in upcoming releases (ie 3.2.0 of them), in >> >> plugins >> >>> m-install-p and m-deploy-p simply "flip" the defaults: and make them >> >>> install/deploy At End by default, while keeping the ability to >> "reverse" >> >> if >> >>> someone really depends on per-module deploys. >> >>> >> >>> WDYT? >> >>> >> >>> Thanks >> >>> T >> >>> >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >>
