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 > >
