Le mar. 30 mars 2021 à 19:58, Benjamin Marwell <bmarw...@apache.org> a écrit :
> The class cache is also available since Java 8 in the OpenJ9 VM, which also > has faster startup times in most cases (for me). > Not sure if the scc is portable when using different Java language levels, > though. > It is still about app classloader so in maven it is plexus-classword so ~30 classes (guess maven has a bit more) so will not have much impact. > > But you can give it a try: > > https://www.eclipse.org/openj9/docs/shrc/ > > 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? > Save there, it is really a big helper. Has some potential enhancements but it is really a big plus for maven users and a long overdue feature (IIRC we were already speaking about it 10 years ago with colleagues). > > Tbh, I expected more mails on this thread. > > > > On Mon, 29 Mar 2021, 20:49 Romain Manni-Bucau, <rmannibu...@gmail.com> > wrote: > > > Le lun. 29 mars 2021 à 19:26, Markus KARG <mar...@headcrashing.eu> 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:rmannibu...@gmail.com] > > > 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 < > > > jeffjen...@upstairstechnology.com> > > > 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 <jason.dil...@gmail.com > > > > > > 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: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > >
