Le lun. 29 mars 2021 à 19:26, Markus KARG <[email protected]> a écrit :
> Looking at the impressively reduced bootstrap times of modern JDKs with > features like Automatic AppCDS, I wonder if in the year 2021 this still > makes sense? In rather near future there will be native precompilation > available in most JDKs, effectively reducing bootstrap time to few ms. So > is it worth investing this time and complexity? In the past, yes, up to JDK > 8, it definitively was. But NOW? > Yep it makes sense more than ever IMHO because nothing actually changed for maven: 1. CDS impact on maven is more or less 0 since maven bootstrap everything in subclassloaders of the app loader and it is the only one able to benefit from it (+ it is not the main benefit of a daemon, it also bypasses resolution and all other steps the JVM will never do since it must be maven aware) 2. Making it GraalVM - ignoring the effort required to do it, run it on CI (in time) and maintain it - will not help much for the same daemon goal reason So is it worth doing a daemon -> clearly, this is what mvnd proves (leveraging a mvnd client in native mode when possible btw). > > -Markus > > > -----Ursprüngliche Nachricht----- > Von: Romain Manni-Bucau [mailto:[email protected]] > Gesendet: Montag, 29. März 2021 12:21 > An: Maven Developers List > Cc: Jason Dillon > Betreff: Re: Why no mvn daemon? > > Up 4 years later ;) > > Now mvnd exists and proves it is very interesting to have such a feature, > should it be something which can fit maven standard delivery? > If overall yes we can start by asking mvnd if it can be contributed with > main codebase and if not we can either decide to do our own (hope not ;)) > or that maven does not care about caching/optimizations in its "core" and > that it is only done in extensions (I know 3 "main" ones as of today). > > Wdyt? > > 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 mer. 9 mars 2016 à 23:58, Jeff Jensen < > [email protected]> > a écrit : > > > Thanks! It's running just fine. :-) It's very cool. Really nice > > directory traversal and completion, colors, and commands/features I don't > > know yet! > > > > Very interesting timing diffs (for each casual test, I ran the command > for > > each multiple times to seed infra caches): > > * on some asciidoc gen with "mvn generate-resources", it was about the > > same duration as CLI but after running each about 10 times, mvnshell > saved > > about 20% consistently (possibly due to JIT? besides directory traversal, > > this was the first things I did). This was my key use case for wanting a > > "mvn server" - handling situations like this with repeated runs > (asciidoc, > > site, etc.). > > > > * on a simple "mvn clean", mvnshell was about 2x faster than CLI. > > > > * on a small module build, "mvn install" was about 20% faster over CLI > > (after a mvn clean for each). > > > > I look forward to trying more things. > > > > Nice to have, thank you Jason! > > > > > > On Wed, Mar 9, 2016 at 4:17 PM, Jason Dillon <[email protected]> > > wrote: > > > > > Jason, if you have a built version, do you mind adding it as a download > > to > > > > > > the release files? > > > > > > I can make a binary of this, though I do plan on fixing it up so that > > > folks can build it in the near future. > > > > > > Build up here for the moment: > > > > > > > > > https://www.dropbox.com/sh/yvt1g43r2pr2scj/AADqM__VhJaFf_x57OiUEZXva?dl=0 > > > > > > gshell:master should be buildable with just central now, dangling ref > to > > > older version of jline for classifer=tests which was unused and > polluting > > > the build dependencies. > > > > > > —jason > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
