Hi I'm mixed about it since I have a lot of projects using the fact a previous module was installed in default repo. While I can understand the intent I also think both make sense so I don't think why we should break existing projects (when there are two values and both are needed I'd priviledge the backward compat one).
Side note: indeed this does not work with split repo but this one has more issues for my cases so this will not be enabled like that so not a topic there. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 14 juin 2024 à 21:04, Tamás Cservenák <ta...@cservenak.net> a écrit : > 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 > >> > >> >
