You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Guillaume Nodet <gn...@apache.org> on 2021/04/07 06:34:17 UTC
Re: Why no mvn daemon?
Fwiw, Peter and I would be happy to donate mvnd to the Apache Maven
project, should you choose to accept it.
Cheers,
Guillaume
Le lun. 29 mars 2021 à 12:21, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
> 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 <
> jeffjensen@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 <ja...@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
> > >
> > >
> > >
> >
>
--
------------------------
Guillaume Nodet
Re: Why no mvn daemon?
Posted by Olivier Lamy <ol...@apache.org>.
Hi
Yes doesn't look to be an issue.
We can definitely simply create the git repo and push the current one.
The project is already under ASF license and 2 main contributors are ASF
committers.
Not sure we need to search for a needle in the haystack with this simple
case?
Thoughts?
an ip clearance paperwork?
On Mon, 3 May 2021 at 16:57, Guillaume Nodet <gn...@apache.org> wrote:
> Yes, we're still willing to donate it to maven.
> The IP has already been looked upon some time ago. The two main committers
> are Peter Palage and me and we already are ASF committers. The other
> contributors' contributions do not exceed more than a few lines so I don't
> think this should be an issue, but I can double check.
>
> Le mer. 28 avr. 2021 à 08:50, Olivier Lamy <ol...@apache.org> a écrit :
>
> > Hi
> > What is the status regarding this?
> > @Guillaume Still keen to donate it?
> > Should be very easy as It looks the license is already ASF and most of
> the
> > contributors are already Apache folks.
> > let me know.
> > cheers
> > Olivier
> >
> > On Thu, 8 Apr 2021 at 10:08, Olivier Lamy <ol...@apache.org> wrote:
> >
> > > Sounds great Guillaume!
> > > Not sure to have it part of default distribution but looks to be a
> great
> > > addition here.
> > > Not sure about ip clearance etc... something to manage of course...
> > >
> > > Not tested but should make our plugins build faster? I mean all build
> > > using invoker plugin and keep restarting jvm
> > >
> > >
> > > On Wed, 7 Apr 2021 at 4:34 pm, Guillaume Nodet <gn...@apache.org>
> > wrote:
> > >
> > >> Fwiw, Peter and I would be happy to donate mvnd to the Apache Maven
> > >> project, should you choose to accept it.
> > >>
> > >> Cheers,
> > >> Guillaume
> > >>
> > >> Le lun. 29 mars 2021 à 12:21, Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > >> a
> > >> écrit :
> > >>
> > >> > 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 <
> > >> > jeffjensen@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.dillon@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
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >>
> > >> --
> > >> ------------------------
> > >> Guillaume Nodet
> > >>
> > > --
> > > Olivier Lamy
> > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >
> >
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>
--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Why no mvn daemon?
Posted by Guillaume Nodet <gn...@apache.org>.
Yes, we're still willing to donate it to maven.
The IP has already been looked upon some time ago. The two main committers
are Peter Palage and me and we already are ASF committers. The other
contributors' contributions do not exceed more than a few lines so I don't
think this should be an issue, but I can double check.
Le mer. 28 avr. 2021 à 08:50, Olivier Lamy <ol...@apache.org> a écrit :
> Hi
> What is the status regarding this?
> @Guillaume Still keen to donate it?
> Should be very easy as It looks the license is already ASF and most of the
> contributors are already Apache folks.
> let me know.
> cheers
> Olivier
>
> On Thu, 8 Apr 2021 at 10:08, Olivier Lamy <ol...@apache.org> wrote:
>
> > Sounds great Guillaume!
> > Not sure to have it part of default distribution but looks to be a great
> > addition here.
> > Not sure about ip clearance etc... something to manage of course...
> >
> > Not tested but should make our plugins build faster? I mean all build
> > using invoker plugin and keep restarting jvm
> >
> >
> > On Wed, 7 Apr 2021 at 4:34 pm, Guillaume Nodet <gn...@apache.org>
> wrote:
> >
> >> Fwiw, Peter and I would be happy to donate mvnd to the Apache Maven
> >> project, should you choose to accept it.
> >>
> >> Cheers,
> >> Guillaume
> >>
> >> Le lun. 29 mars 2021 à 12:21, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> >> a
> >> écrit :
> >>
> >> > 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 <
> >> > jeffjensen@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.dillon@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
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> >>
> >> --
> >> ------------------------
> >> Guillaume Nodet
> >>
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
--
------------------------
Guillaume Nodet
Re: Why no mvn daemon?
Posted by Olivier Lamy <ol...@apache.org>.
Hi
What is the status regarding this?
@Guillaume Still keen to donate it?
Should be very easy as It looks the license is already ASF and most of the
contributors are already Apache folks.
let me know.
cheers
Olivier
On Thu, 8 Apr 2021 at 10:08, Olivier Lamy <ol...@apache.org> wrote:
> Sounds great Guillaume!
> Not sure to have it part of default distribution but looks to be a great
> addition here.
> Not sure about ip clearance etc... something to manage of course...
>
> Not tested but should make our plugins build faster? I mean all build
> using invoker plugin and keep restarting jvm
>
>
> On Wed, 7 Apr 2021 at 4:34 pm, Guillaume Nodet <gn...@apache.org> wrote:
>
>> Fwiw, Peter and I would be happy to donate mvnd to the Apache Maven
>> project, should you choose to accept it.
>>
>> Cheers,
>> Guillaume
>>
>> Le lun. 29 mars 2021 à 12:21, Romain Manni-Bucau <rm...@gmail.com>
>> a
>> écrit :
>>
>> > 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 <
>> > jeffjensen@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 <ja...@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
>> > > >
>> > > >
>> > > >
>> > >
>> >
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Why no mvn daemon?
Posted by Olivier Lamy <ol...@apache.org>.
Sounds great Guillaume!
Not sure to have it part of default distribution but looks to be a great
addition here.
Not sure about ip clearance etc... something to manage of course...
Not tested but should make our plugins build faster? I mean all build using
invoker plugin and keep restarting jvm
On Wed, 7 Apr 2021 at 4:34 pm, Guillaume Nodet <gn...@apache.org> wrote:
> Fwiw, Peter and I would be happy to donate mvnd to the Apache Maven
> project, should you choose to accept it.
>
> Cheers,
> Guillaume
>
> Le lun. 29 mars 2021 à 12:21, Romain Manni-Bucau <rm...@gmail.com> a
> écrit :
>
> > 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 <
> > jeffjensen@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 <ja...@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
> > > >
> > > >
> > > >
> > >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>
--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Why no mvn daemon?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 7 avr. 2021 à 19:32, Tibor Digana <ti...@apache.org> a écrit :
> What was the third run? It was one thread with GraalVM?
>
2nd run with mvnd (i skipped the first one since normally you start it once
for you work day)
mvnd client is a graalvm binary but that is a detail since it runs in a jvm
an actual maven build as mvn script does
as mentionned, you will not get a graalvm binary of maven as of today
without loosing all maven features (or doing a hardcoded maven lifecycle
which is unintended)
to be concrete you have:
1. default mvn build
2. standard maven build with concurrency as in mvnd defaults
3. run on a "hot"/ready mvnd instance (~= already running maven)
to present it differently, mvnd is close to what itellij can do with its
remote maven runner, just a bit more optimized and not tied to an IDE
> $ time mvnd install -DskipTests -Dinvoker.skip=true
> real 0m11,295s
> user 0m0,354s
> sys 0m0,176s
>
> On Wed, Apr 7, 2021 at 7:09 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Le mer. 7 avr. 2021 à 17:08, Tibor Digana <ti...@apache.org> a
> > écrit :
> >
> > > Romain, our builds are always downloading the artifacts.
> > > The I/O cannot be 0 time. We invest in safety builds rather than
> > > performance and so we rather download fresh artifacts.
> > > Other teams may cach the artifacts which may not be always so safe -
> > other
> > > preferences.
> > >
> >
> > Got it, note that redownloading a release is normally wrong and caching a
> > snapshot is also but this is your policy and a docker solution will not
> > solve that since you will need to update the docker base image as often
> as
> > you want updates (likely daily for snapshot) or still use snapshots so at
> > the end docker is not what helps *for this factor*.
> >
> >
> > >
> > > If you think that the Cache or AppCDS or GraalVM would have an effect,
> > feel
> > > free to make a prototype and try to measure the performance.
> > > Publish the benchmark test result and we will see how big percentage
> > > improvement it would be in categories (asciidoc, normal build, specific
> > > builds, whatever...)
> > >
> >
> > We already discussed it multiple times but graalvm boost or cds boost can
> > be siginificative but without rewriting *all* maven design gain is 0
> (both
> > only work with a flat classpath - even a bit more constraints) so it
> means
> > no more isolated plugins, no more plexus-classworld etc, not sure we want
> > to do that anytime soon since it is a big feature of maven.
> >
> >
> > >
> > > As I can see the following article, such a benchmark test can be made
> in
> > a
> > > spare time:
> > >
> > >
> >
> https://medium.com/@toparvion/appcds-for-spring-boot-applications-first-contact-6216db6a4194
> >
> >
> > Figures already had been shared on the list and it is not rare to have
> > around 30% boost on real life projects.
> > If you want something closer, maven-surefire figures are:
> >
> > $ time mvn install -DskipTests -Dinvoker.skip=true
> > real 0m29,606s
> > user 2m10,142s
> > sys 0m3,160s
> >
> > $ time mvn install -DskipTests -Dinvoker.skip=true -T15 # I have 16 core,
> > just to match mvnd defaults
> > real 0m19,494s
> > user 2m47,651s
> > sys 0m4,098s
> >
> > $ time mvnd install -DskipTests -Dinvoker.skip=true
> > real 0m11,295s
> > user 0m0,354s
> > sys 0m0,176s
> >
> >
> > 42% faster (I skipped tests to only include project pipeline but it is
> the
> > kind of boost the caching + long running daemon provides you)
> >
> >
> >
> > >
> > >
> > >
> > > Cheers
> > > T
> > >
> > >
> > > On Wed, Apr 7, 2021 at 3:52 PM Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > > wrote:
> > >
> > > > Hi Tibor,
> > > >
> > > > I see what you mean but I think this topic is actually unrelated to
> IO
> > > > since this remote latency is actually 0 in the case we are discussing
> > and
> > > > this case is generally solved by caching on all CI (jenkins, gh
> > actions,
> > > > travis for the ones I can speak about out of my head) - and locally
> by
> > > your
> > > > local m2 as you mentionned.
> > > > So overall the download time is always skipped in this daemon topic
> > since
> > > > it is a pay once cost that devs rarely face.
> > > >
> > > > What we care about is to a have sane defaults and the capacity to
> stop
> > > > creating and recreating ClassRealm with potentially slow init in
> these
> > > > realms (use asciidoctor to see something slow to create ;)).
> > > > A daemon enables to add a ton of caches which save a lot of time in
> > > > practise when rebuilding the same project.
> > > > Indeed part of these enhancements can be backported to maven core -
> and
> > > > thanks mvnd team to have done part of it - but not all of them since
> by
> > > > design the biggest slow part of a JVM is the classloading (it is one
> > part
> > > > GraalVM speeds up a lot by bypassing it), in particular with plexus
> > > > classrealm hierarchy and impl.
> > > > At least this feature can justify a daemon for me but also having an
> in
> > > > memory cache to not resolving and resolving is the second big feature
> > > maven
> > > > benefits a lot from what I saw (it is crazy how we loose time there).
> > > > Indeed, as soon as instances can be reused plugins could cache more
> > > without
> > > > breaking the "not daemon" cache and provide way more boosts but
> current
> > > > behavior is already impressive (I expected the boost to be important
> > but
> > > > less when I started the thread 4 years ago to be honest).
> > > >
> > > > Le mer. 7 avr. 2021 à 15:40, Tibor Digana <ti...@apache.org> a
> > > > écrit :
> > > >
> > > > > I think two years ago we were talking about Maven dockerization.
> > > > > We had the work in progress and I think I will be able to find it
> > > again.
> > > > > The Docker image included local repo.
> > > > > I think the biggest latencies are when you are downloading
> artifacts.
> > > >
> > > > Of course, you have one local repo, but that's suitable for those CI
> > > > > systems which do not want to override the local repo or share the
> > > > artifacts
> > > > > with other projects. It is our case in Apache.
> > > > >
> > > > > T
> > > > >
> > > > > On Wed, Apr 7, 2021 at 8:34 AM Guillaume Nodet <gn...@apache.org>
> > > > wrote:
> > > > >
> > > > > > Fwiw, Peter and I would be happy to donate mvnd to the Apache
> Maven
> > > > > > project, should you choose to accept it.
> > > > > >
> > > > > > Cheers,
> > > > > > Guillaume
> > > > > >
> > > > > > Le lun. 29 mars 2021 à 12:21, Romain Manni-Bucau <
> > > > rmannibucau@gmail.com>
> > > > > a
> > > > > > écrit :
> > > > > >
> > > > > > > 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 <
> > > > > > > jeffjensen@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.dillon@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
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > ------------------------
> > > > > > Guillaume Nodet
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Why no mvn daemon?
Posted by Tibor Digana <ti...@apache.org>.
What was the third run? It was one thread with GraalVM?
$ time mvnd install -DskipTests -Dinvoker.skip=true
real 0m11,295s
user 0m0,354s
sys 0m0,176s
On Wed, Apr 7, 2021 at 7:09 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Le mer. 7 avr. 2021 à 17:08, Tibor Digana <ti...@apache.org> a
> écrit :
>
> > Romain, our builds are always downloading the artifacts.
> > The I/O cannot be 0 time. We invest in safety builds rather than
> > performance and so we rather download fresh artifacts.
> > Other teams may cach the artifacts which may not be always so safe -
> other
> > preferences.
> >
>
> Got it, note that redownloading a release is normally wrong and caching a
> snapshot is also but this is your policy and a docker solution will not
> solve that since you will need to update the docker base image as often as
> you want updates (likely daily for snapshot) or still use snapshots so at
> the end docker is not what helps *for this factor*.
>
>
> >
> > If you think that the Cache or AppCDS or GraalVM would have an effect,
> feel
> > free to make a prototype and try to measure the performance.
> > Publish the benchmark test result and we will see how big percentage
> > improvement it would be in categories (asciidoc, normal build, specific
> > builds, whatever...)
> >
>
> We already discussed it multiple times but graalvm boost or cds boost can
> be siginificative but without rewriting *all* maven design gain is 0 (both
> only work with a flat classpath - even a bit more constraints) so it means
> no more isolated plugins, no more plexus-classworld etc, not sure we want
> to do that anytime soon since it is a big feature of maven.
>
>
> >
> > As I can see the following article, such a benchmark test can be made in
> a
> > spare time:
> >
> >
> https://medium.com/@toparvion/appcds-for-spring-boot-applications-first-contact-6216db6a4194
>
>
> Figures already had been shared on the list and it is not rare to have
> around 30% boost on real life projects.
> If you want something closer, maven-surefire figures are:
>
> $ time mvn install -DskipTests -Dinvoker.skip=true
> real 0m29,606s
> user 2m10,142s
> sys 0m3,160s
>
> $ time mvn install -DskipTests -Dinvoker.skip=true -T15 # I have 16 core,
> just to match mvnd defaults
> real 0m19,494s
> user 2m47,651s
> sys 0m4,098s
>
> $ time mvnd install -DskipTests -Dinvoker.skip=true
> real 0m11,295s
> user 0m0,354s
> sys 0m0,176s
>
>
> 42% faster (I skipped tests to only include project pipeline but it is the
> kind of boost the caching + long running daemon provides you)
>
>
>
> >
> >
> >
> > Cheers
> > T
> >
> >
> > On Wed, Apr 7, 2021 at 3:52 PM Romain Manni-Bucau <rmannibucau@gmail.com
> >
> > wrote:
> >
> > > Hi Tibor,
> > >
> > > I see what you mean but I think this topic is actually unrelated to IO
> > > since this remote latency is actually 0 in the case we are discussing
> and
> > > this case is generally solved by caching on all CI (jenkins, gh
> actions,
> > > travis for the ones I can speak about out of my head) - and locally by
> > your
> > > local m2 as you mentionned.
> > > So overall the download time is always skipped in this daemon topic
> since
> > > it is a pay once cost that devs rarely face.
> > >
> > > What we care about is to a have sane defaults and the capacity to stop
> > > creating and recreating ClassRealm with potentially slow init in these
> > > realms (use asciidoctor to see something slow to create ;)).
> > > A daemon enables to add a ton of caches which save a lot of time in
> > > practise when rebuilding the same project.
> > > Indeed part of these enhancements can be backported to maven core - and
> > > thanks mvnd team to have done part of it - but not all of them since by
> > > design the biggest slow part of a JVM is the classloading (it is one
> part
> > > GraalVM speeds up a lot by bypassing it), in particular with plexus
> > > classrealm hierarchy and impl.
> > > At least this feature can justify a daemon for me but also having an in
> > > memory cache to not resolving and resolving is the second big feature
> > maven
> > > benefits a lot from what I saw (it is crazy how we loose time there).
> > > Indeed, as soon as instances can be reused plugins could cache more
> > without
> > > breaking the "not daemon" cache and provide way more boosts but current
> > > behavior is already impressive (I expected the boost to be important
> but
> > > less when I started the thread 4 years ago to be honest).
> > >
> > > Le mer. 7 avr. 2021 à 15:40, Tibor Digana <ti...@apache.org> a
> > > écrit :
> > >
> > > > I think two years ago we were talking about Maven dockerization.
> > > > We had the work in progress and I think I will be able to find it
> > again.
> > > > The Docker image included local repo.
> > > > I think the biggest latencies are when you are downloading artifacts.
> > >
> > > Of course, you have one local repo, but that's suitable for those CI
> > > > systems which do not want to override the local repo or share the
> > > artifacts
> > > > with other projects. It is our case in Apache.
> > > >
> > > > T
> > > >
> > > > On Wed, Apr 7, 2021 at 8:34 AM Guillaume Nodet <gn...@apache.org>
> > > wrote:
> > > >
> > > > > Fwiw, Peter and I would be happy to donate mvnd to the Apache Maven
> > > > > project, should you choose to accept it.
> > > > >
> > > > > Cheers,
> > > > > Guillaume
> > > > >
> > > > > Le lun. 29 mars 2021 à 12:21, Romain Manni-Bucau <
> > > rmannibucau@gmail.com>
> > > > a
> > > > > écrit :
> > > > >
> > > > > > 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 <
> > > > > > jeffjensen@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.dillon@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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > ------------------------
> > > > > Guillaume Nodet
> > > > >
> > > >
> > >
> >
>
Re: Why no mvn daemon?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 7 avr. 2021 à 17:08, Tibor Digana <ti...@apache.org> a écrit :
> Romain, our builds are always downloading the artifacts.
> The I/O cannot be 0 time. We invest in safety builds rather than
> performance and so we rather download fresh artifacts.
> Other teams may cach the artifacts which may not be always so safe - other
> preferences.
>
Got it, note that redownloading a release is normally wrong and caching a
snapshot is also but this is your policy and a docker solution will not
solve that since you will need to update the docker base image as often as
you want updates (likely daily for snapshot) or still use snapshots so at
the end docker is not what helps *for this factor*.
>
> If you think that the Cache or AppCDS or GraalVM would have an effect, feel
> free to make a prototype and try to measure the performance.
> Publish the benchmark test result and we will see how big percentage
> improvement it would be in categories (asciidoc, normal build, specific
> builds, whatever...)
>
We already discussed it multiple times but graalvm boost or cds boost can
be siginificative but without rewriting *all* maven design gain is 0 (both
only work with a flat classpath - even a bit more constraints) so it means
no more isolated plugins, no more plexus-classworld etc, not sure we want
to do that anytime soon since it is a big feature of maven.
>
> As I can see the following article, such a benchmark test can be made in a
> spare time:
>
> https://medium.com/@toparvion/appcds-for-spring-boot-applications-first-contact-6216db6a4194
Figures already had been shared on the list and it is not rare to have
around 30% boost on real life projects.
If you want something closer, maven-surefire figures are:
$ time mvn install -DskipTests -Dinvoker.skip=true
real 0m29,606s
user 2m10,142s
sys 0m3,160s
$ time mvn install -DskipTests -Dinvoker.skip=true -T15 # I have 16 core,
just to match mvnd defaults
real 0m19,494s
user 2m47,651s
sys 0m4,098s
$ time mvnd install -DskipTests -Dinvoker.skip=true
real 0m11,295s
user 0m0,354s
sys 0m0,176s
42% faster (I skipped tests to only include project pipeline but it is the
kind of boost the caching + long running daemon provides you)
>
>
>
> Cheers
> T
>
>
> On Wed, Apr 7, 2021 at 3:52 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Hi Tibor,
> >
> > I see what you mean but I think this topic is actually unrelated to IO
> > since this remote latency is actually 0 in the case we are discussing and
> > this case is generally solved by caching on all CI (jenkins, gh actions,
> > travis for the ones I can speak about out of my head) - and locally by
> your
> > local m2 as you mentionned.
> > So overall the download time is always skipped in this daemon topic since
> > it is a pay once cost that devs rarely face.
> >
> > What we care about is to a have sane defaults and the capacity to stop
> > creating and recreating ClassRealm with potentially slow init in these
> > realms (use asciidoctor to see something slow to create ;)).
> > A daemon enables to add a ton of caches which save a lot of time in
> > practise when rebuilding the same project.
> > Indeed part of these enhancements can be backported to maven core - and
> > thanks mvnd team to have done part of it - but not all of them since by
> > design the biggest slow part of a JVM is the classloading (it is one part
> > GraalVM speeds up a lot by bypassing it), in particular with plexus
> > classrealm hierarchy and impl.
> > At least this feature can justify a daemon for me but also having an in
> > memory cache to not resolving and resolving is the second big feature
> maven
> > benefits a lot from what I saw (it is crazy how we loose time there).
> > Indeed, as soon as instances can be reused plugins could cache more
> without
> > breaking the "not daemon" cache and provide way more boosts but current
> > behavior is already impressive (I expected the boost to be important but
> > less when I started the thread 4 years ago to be honest).
> >
> > Le mer. 7 avr. 2021 à 15:40, Tibor Digana <ti...@apache.org> a
> > écrit :
> >
> > > I think two years ago we were talking about Maven dockerization.
> > > We had the work in progress and I think I will be able to find it
> again.
> > > The Docker image included local repo.
> > > I think the biggest latencies are when you are downloading artifacts.
> >
> > Of course, you have one local repo, but that's suitable for those CI
> > > systems which do not want to override the local repo or share the
> > artifacts
> > > with other projects. It is our case in Apache.
> > >
> > > T
> > >
> > > On Wed, Apr 7, 2021 at 8:34 AM Guillaume Nodet <gn...@apache.org>
> > wrote:
> > >
> > > > Fwiw, Peter and I would be happy to donate mvnd to the Apache Maven
> > > > project, should you choose to accept it.
> > > >
> > > > Cheers,
> > > > Guillaume
> > > >
> > > > Le lun. 29 mars 2021 à 12:21, Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > a
> > > > écrit :
> > > >
> > > > > 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 <
> > > > > jeffjensen@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.dillon@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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
> > > >
> > >
> >
>
Re: Why no mvn daemon?
Posted by Tibor Digana <ti...@apache.org>.
Romain, our builds are always downloading the artifacts.
The I/O cannot be 0 time. We invest in safety builds rather than
performance and so we rather download fresh artifacts.
Other teams may cach the artifacts which may not be always so safe - other
preferences.
If you think that the Cache or AppCDS or GraalVM would have an effect, feel
free to make a prototype and try to measure the performance.
Publish the benchmark test result and we will see how big percentage
improvement it would be in categories (asciidoc, normal build, specific
builds, whatever...)
As I can see the following article, such a benchmark test can be made in a
spare time:
https://medium.com/@toparvion/appcds-for-spring-boot-applications-first-contact-6216db6a4194
Cheers
T
On Wed, Apr 7, 2021 at 3:52 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hi Tibor,
>
> I see what you mean but I think this topic is actually unrelated to IO
> since this remote latency is actually 0 in the case we are discussing and
> this case is generally solved by caching on all CI (jenkins, gh actions,
> travis for the ones I can speak about out of my head) - and locally by your
> local m2 as you mentionned.
> So overall the download time is always skipped in this daemon topic since
> it is a pay once cost that devs rarely face.
>
> What we care about is to a have sane defaults and the capacity to stop
> creating and recreating ClassRealm with potentially slow init in these
> realms (use asciidoctor to see something slow to create ;)).
> A daemon enables to add a ton of caches which save a lot of time in
> practise when rebuilding the same project.
> Indeed part of these enhancements can be backported to maven core - and
> thanks mvnd team to have done part of it - but not all of them since by
> design the biggest slow part of a JVM is the classloading (it is one part
> GraalVM speeds up a lot by bypassing it), in particular with plexus
> classrealm hierarchy and impl.
> At least this feature can justify a daemon for me but also having an in
> memory cache to not resolving and resolving is the second big feature maven
> benefits a lot from what I saw (it is crazy how we loose time there).
> Indeed, as soon as instances can be reused plugins could cache more without
> breaking the "not daemon" cache and provide way more boosts but current
> behavior is already impressive (I expected the boost to be important but
> less when I started the thread 4 years ago to be honest).
>
> Le mer. 7 avr. 2021 à 15:40, Tibor Digana <ti...@apache.org> a
> écrit :
>
> > I think two years ago we were talking about Maven dockerization.
> > We had the work in progress and I think I will be able to find it again.
> > The Docker image included local repo.
> > I think the biggest latencies are when you are downloading artifacts.
>
> Of course, you have one local repo, but that's suitable for those CI
> > systems which do not want to override the local repo or share the
> artifacts
> > with other projects. It is our case in Apache.
> >
> > T
> >
> > On Wed, Apr 7, 2021 at 8:34 AM Guillaume Nodet <gn...@apache.org>
> wrote:
> >
> > > Fwiw, Peter and I would be happy to donate mvnd to the Apache Maven
> > > project, should you choose to accept it.
> > >
> > > Cheers,
> > > Guillaume
> > >
> > > Le lun. 29 mars 2021 à 12:21, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > a
> > > écrit :
> > >
> > > > 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 <
> > > > jeffjensen@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.dillon@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
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> >
>
Re: Why no mvn daemon?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Tibor,
I see what you mean but I think this topic is actually unrelated to IO
since this remote latency is actually 0 in the case we are discussing and
this case is generally solved by caching on all CI (jenkins, gh actions,
travis for the ones I can speak about out of my head) - and locally by your
local m2 as you mentionned.
So overall the download time is always skipped in this daemon topic since
it is a pay once cost that devs rarely face.
What we care about is to a have sane defaults and the capacity to stop
creating and recreating ClassRealm with potentially slow init in these
realms (use asciidoctor to see something slow to create ;)).
A daemon enables to add a ton of caches which save a lot of time in
practise when rebuilding the same project.
Indeed part of these enhancements can be backported to maven core - and
thanks mvnd team to have done part of it - but not all of them since by
design the biggest slow part of a JVM is the classloading (it is one part
GraalVM speeds up a lot by bypassing it), in particular with plexus
classrealm hierarchy and impl.
At least this feature can justify a daemon for me but also having an in
memory cache to not resolving and resolving is the second big feature maven
benefits a lot from what I saw (it is crazy how we loose time there).
Indeed, as soon as instances can be reused plugins could cache more without
breaking the "not daemon" cache and provide way more boosts but current
behavior is already impressive (I expected the boost to be important but
less when I started the thread 4 years ago to be honest).
Le mer. 7 avr. 2021 à 15:40, Tibor Digana <ti...@apache.org> a écrit :
> I think two years ago we were talking about Maven dockerization.
> We had the work in progress and I think I will be able to find it again.
> The Docker image included local repo.
> I think the biggest latencies are when you are downloading artifacts.
Of course, you have one local repo, but that's suitable for those CI
> systems which do not want to override the local repo or share the artifacts
> with other projects. It is our case in Apache.
>
> T
>
> On Wed, Apr 7, 2021 at 8:34 AM Guillaume Nodet <gn...@apache.org> wrote:
>
> > Fwiw, Peter and I would be happy to donate mvnd to the Apache Maven
> > project, should you choose to accept it.
> >
> > Cheers,
> > Guillaume
> >
> > Le lun. 29 mars 2021 à 12:21, Romain Manni-Bucau <rm...@gmail.com>
> a
> > écrit :
> >
> > > 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 <
> > > jeffjensen@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.dillon@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
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
>
Re: Why no mvn daemon?
Posted by Tibor Digana <ti...@apache.org>.
I think two years ago we were talking about Maven dockerization.
We had the work in progress and I think I will be able to find it again.
The Docker image included local repo.
I think the biggest latencies are when you are downloading artifacts.
Of course, you have one local repo, but that's suitable for those CI
systems which do not want to override the local repo or share the artifacts
with other projects. It is our case in Apache.
T
On Wed, Apr 7, 2021 at 8:34 AM Guillaume Nodet <gn...@apache.org> wrote:
> Fwiw, Peter and I would be happy to donate mvnd to the Apache Maven
> project, should you choose to accept it.
>
> Cheers,
> Guillaume
>
> Le lun. 29 mars 2021 à 12:21, Romain Manni-Bucau <rm...@gmail.com> a
> écrit :
>
> > 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 <
> > jeffjensen@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 <ja...@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
> > > >
> > > >
> > > >
> > >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>