Howdy, Everybody has "quirks", and your project "using the fact a previous module was installed" is probably an exception. For example no Maven project expects this (and we have circa 200 of them?). Anyway, -DdeployAtEnd=false is your friend then (maybe best in .mvn/maven.config).
Thanks T On Fri, Jun 14, 2024 at 9:21 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > 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 > > >> > > >> > > >
