I think there is a point in making better build times. Complexity which comes from native compilation is there and its going to stay.
I find mvnd useful for projects which are staying with mainstream JDKs (11 and below) and will eventually migrate to edge ones (12 or 13+) in coming years. It took quite a bit for Java 8 to take over Java 5/6/7. Faster releases and more features in runtime doesn't mean that everyone will switch immediately. I can also speak of myself - I use mvnd in growing amount of builds and my plan is to keep using it. I do have one build with project which luckily migrated out from tycho - this one doesn't work, all other work just fine. I found this topic by an accident. If you seek opinions about mvnd maybe its better to make survey over official twitter account. Best, Łukasz On 30.03.2021 19:58, Benjamin Marwell wrote: > 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. > > 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? > > Tbh, I expected more mails on this thread. > > > > On Mon, 29 Mar 2021, 20:49 Romain Manni-Bucau, <[email protected]> > wrote: > >> 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] >>> >>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
