Hi, maybe an artifact recorder is in fact the real need here… so if some module is built, the generated artifacts should be accessible to subsequent maven executions…. this way an install would be superfluous and multiple builds could be run after each other without changing the installed heap.
Only in case of success the recorded artifacts would be installed and/or deployed. I used this technique to build a huge project and run numerous integration tests. I would write the extension again, if needed. We had non standard artifact attachments that forced to write the extension back then in that project.. > Am 14.06.2024 um 21:20 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > 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 >>>> >>>> >> GF Kemal Soysal __________________________ Kemal Soysal LS IT-Solutions GmbH kemal.soy...@ls-it-solutions.de Mobil: +49 1512 404 55 66 Thomas-Mann-Str.21 44141 Dortmund
