Add my +10000 to Romain's. As said, it is drop-in replacement most of the times, has a nice TUI, sane defaults and speeds up your build.
If you haven't tried it yet, definitely do. As for the resident memory: no software is ever finished, there will always be something which can be done better. I don't mind, we can make it better if we want to. That's why we're here in the first place, no? 😉 Haven't tried it on Jenkins nor GH actions, though. But I don't remember I built shiro without mvnd. It's just so much faster using 3+ threads (plus you *will* discover badly isolated tests). It also made me rework projects at work into mire modules, which also lead to (imho) better design, as we now have better encapsulated responsibility (and extra API projects for CDI) PLUS faster builds. - Ben On Wed, 31 Mar 2021, 08:52 Romain Manni-Bucau, <rmannibu...@gmail.com> wrote: > Le mer. 31 mars 2021 à 08:17, Hervé BOUTEMY <herve.bout...@free.fr> a > écrit : > > > I think mvnd is not so well known [1]: I did never test it, I should > > probably > > do... > > > > and as incremental compilation discussion have started recently, we'll > > need to > > have a global discussion on evaluating and eventually mixing differents > > ways of > > improving build performance > > > > +100000, mvnd is awesome but solves the JVM pitfalls mainly, incremental > support is per mojo to be optimized and both would be awesome. > Basically optimizing the JVM + the runtime at the same time. > > > > > > when evaluating, I think we'll need to keep in mind one key aspect: from > a > > user perspective, which deployment and usage complexities does every > > solution > > bring for which performance improvement? > > > > I think the main one maven should target is the "local" env (this is why > mvnd fits so well) - by opposition of a remote server as gradle enterprise > one which requires some infra, typically maven does not produce nexus byt > stick on local software and I think it is sane to target it primarly. > > > > > > I feel that each solution that brings more expected performance > > improvement > > comes with at least a deployment complexity, perhaps sometimes use > > complexity > > also (per-project configuration, ...) > > > > Hmm, here the only drawback of mvnd is to have the daemon running and > consume the related memory but it is also why you use it so it is almost > free for me - at least in usage. It is not like having to setup a server > and configure the client in maven since launching mvnd instead of mvn you > launch the mvnd client + the daemon if not already running so in terms of > user experience you can alias mvn=mvnd and you will not notice the > difference if you have enough memory. > My typicall pitfall with 16G of ram is to have idea+chrome+minikube > launched and mvd preventing a graalvm build (not enough memory)...but it is > not mainstream too as memory consumption. > Also there is a ticket about improving mvnd daemon auto-monitoring to kill > itself if machine memory is too low and it is not used ( > https://github.com/mvndaemon/mvnd/issues/364) so this pitfall can > disappear > too. > > > > > > but currently mvnd is the only free solution publicly available: I should > > definitely test it to better know it when we'll have more in depth > > discussions > > in the future > > > > Please keep posting your factual returns on experience: that's definitely > > useful > > > > Regards, > > > > Hervé > > > > [1] https://github.com/mvndaemon/mvnd > > > > Le mardi 30 mars 2021, 22:32:37 CEST Romain Manni-Bucau a écrit : > > > Le mar. 30 mars 2021 à 22:16, Jochen Wiedmann < > jochen.wiedm...@gmail.com> > > a > > > > > > écrit : > > > > On Tue, Mar 30, 2021 at 7:58 PM Benjamin Marwell < > bmarw...@apache.org> > > > > > > > > wrote: > > > > > Other than that, I use mvnd at work and we never had problems on > any > > > > > project. We consistently save time without the need of adding the > -T > > > > > parameter manually. Another big question is probably: is there > enough > > > > > community demand to merge it into core? > > > > > > > > > > Tbh, I expected more mails on this thread. > > > > > > > > The question for me: Who's launching this mvnd? I wouldn't want to > > > > have a dedicated server for that. However, if (for example) m2e would > > > > launch it automatically when I open Eclipse, and perform a shutdown, > > > > when Eclipse closes, then I'd be perfectly happy to use it. > > > > > > mvnd. As soon as env changes (you launch it from another project) > daemon > > is > > > killed. > > > Indeed you can kill it manually too - which makes it saner than idea > > remote > > > maven server or ide maven server which cant be killed generally and > > consume > > > a lot of mem while ide is on. > > > > > > Indeed you can bind mvnd --stop on eclipse shutdown which would behave > as > > > you expect but working on the cli without any ide specific integ is > maven > > > scope, not idea integration IMO (even if a few code enable it but guess > > it > > > is legacy now thanks the ioc mvn has). > > > > > > Feel free to give a try to mvnd, works very well everywhere ;). > > > > > > > Jochen > > > > > > > > > > > > > > > > -- > > > > > > > > Look, that's why there's rules, understand? So that you think before > > > > you break 'em. > > > > > > > > -- (Terry Pratchett, Thief of Time) > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
