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