Re: Why no mvn daemon?

[Olivier Lamy]

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  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  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  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 
> > 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 <
> rmannibu...@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  |  Blog
> > >> >  | Old Blog
> > >> >  | Github <
> > >> > https://github.com/rmannibucau> |
> > >> > LinkedIn  | 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 

Re: Why no mvn daemon?

[Guillaume Nodet]

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  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  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 
> 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  >
> >> 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  |  Blog
> >> >  | Old Blog
> >> >  | Github <
> >> > https://github.com/rmannibucau> |
> >> > LinkedIn  | 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
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> >>
> >> --
> >> 
> >> 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?

[Olivier Lamy]

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  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  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 
>> 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  |  Blog
>> >  | Old Blog
>> >  | Github <
>> > https://github.com/rmannibucau> |
>> > LinkedIn  | 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 
>> > > 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?

[Olivier Lamy]

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  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  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  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | 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 
> > > 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?

[Romain Manni-Bucau]

Le mer. 7 avr. 2021 à 19:32, Tibor Digana  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 
> wrote:
>
> > Le mer. 7 avr. 2021 à 17:08, Tibor Digana  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 <
> rmannibu...@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 

Re: Why no mvn daemon?

[Tibor Digana]

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

> Le mer. 7 avr. 2021 à 17:08, Tibor Digana  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  >
> > 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  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.
> > > >
> > > > 

Re: Why no mvn daemon?

[Romain Manni-Bucau]

Le mer. 7 avr. 2021 à 17:08, Tibor Digana  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 
> 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  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 
> > 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 <
> > rmannibu...@gmail.com>
> > > a
> > > > écrit :
> > > >
> > > > > Up 4 years later ;)
> > > > >
> > > > > Now mvnd exists and proves it is 

Re: Why no mvn daemon?

[Tibor Digana]

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 
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  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 
> 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 <
> rmannibu...@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  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | 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% 

Re: Why no mvn daemon?

[Romain Manni-Bucau]

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  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  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 
> 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  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | 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  >
> > > > 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:
> > > > >
> > > > >
> > > >
> > >
> >
> 

Re: Why no mvn daemon?

[Tibor Digana]

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  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  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  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | 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 
> > > 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?

[Guillaume Nodet]

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  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  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | 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 
> > 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?

[Benjamin Marwell]

Add my +1 to Romain's.
As said, it is drop-in replacement most of the times, has a nice TUI, sane
defaults and speeds up your build.

If you haven't tried it yet, definitely do.

As for the resident memory: no software is ever finished, there will always
be something which can be done better. I don't mind, we can make it better
if we want to. That's why we're here in the first place, no? 

Haven't tried it on Jenkins nor GH actions, though. But I don't remember I
built shiro without mvnd. It's just so much faster using 3+ threads (plus
you *will* discover badly isolated tests). It also made me rework projects
at work into mire modules, which also lead to (imho) better design, as we
now have better encapsulated responsibility (and extra API projects for
CDI) PLUS faster builds.

- Ben


On Wed, 31 Mar 2021, 08:52 Romain Manni-Bucau, 
wrote:

> Le mer. 31 mars 2021 à 08:17, Hervé BOUTEMY  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
> >
>
> +10, 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 

Re: Why no mvn daemon?

[Romain Manni-Bucau]

Le mer. 31 mars 2021 à 08:17, Hervé BOUTEMY  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
>

+10, 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 
> a
> >
> > écrit :
> > > On Tue, Mar 30, 2021 at 7:58 PM Benjamin Marwell 
> > >
> > > 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
>
>

Re: Why no mvn daemon?

[Hervé BOUTEMY]

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

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 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, ...)

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  a
> 
> écrit :
> > On Tue, Mar 30, 2021 at 7:58 PM Benjamin Marwell 
> > 
> > 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

Re: Why no mvn daemon?

[Łukasz Dywicki]

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, 
> wrote:
> 
>> Le lun. 29 mars 2021 à 19:26, Markus KARG  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 mul

Re: Why no mvn daemon?

[Romain Manni-Bucau]

Le mar. 30 mars 2021 à 22:16, Jochen Wiedmann  a
écrit :

> On Tue, Mar 30, 2021 at 7:58 PM Benjamin Marwell 
> 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
>
>

Re: Why no mvn daemon?

[Jochen Wiedmann]

On Tue, Mar 30, 2021 at 7:58 PM Benjamin Marwell  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.

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

Re: Why no mvn daemon?

[Romain Manni-Bucau]

Le mar. 30 mars 2021 à 19:58, Benjamin Marwell  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, 
> wrote:
>
> > Le lun. 29 mars 2021 à 19:26, Markus KARG  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
> > > s

Re: Why no mvn daemon?

[Benjamin Marwell]

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, 
wrote:

> Le lun. 29 mars 2021 à 19:26, Markus KARG  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 
> > > wrote:
> > >
> > > > Jason, if you have a built version, do you mind adding it as a
> download
> > > to
&g

Re: Why no mvn daemon?

[Romain Manni-Bucau]

Le lun. 29 mars 2021 à 19:26, Markus KARG  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 
> > 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
>
>

AW: Why no mvn daemon?

[Markus KARG]

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?

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

Re: Why no mvn daemon?

[Romain Manni-Bucau]

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 9 mars 2016 à 23:58, Jeff Jensen 
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 
> 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
> >
> >
> >
>

Re: Why no mvn daemon?

[Jeff Jensen]

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

Re: Why no mvn daemon?

[Jeff Jensen]

On Wed, Mar 9, 2016 at 3:59 PM, Jason Dillon  wrote:

> On March 8, 2016 at 7:45:53 AM, Jeff Jensen (
> jeffjen...@upstairstechnology.com) wrote:
>
> FYI Just cloned and tried build but Jansi 1.2 is not in Central: "Could not
>
> find artifact org.fusesource.jansi:jansi:jar:1.2".
>
> http://search.maven.org/#search|gav|1|g%3A%22org.fusesource.jansi%22%20AND%20a%3A%22jansi%22
> 
>
>
> I noted the issue tracker no longer exists so replying here to start.
>
> jansi is not declared in the POMs, so assuming transitive. Found it is
> only referenced by
>
> "mvnsh-commands/mvnsh-maven/src/main/java/org/sonatype/maven/shell/commands/maven/ColorizingStream.java"
>
> in mvnsh-commands/mvnsh-maven.
> I'm out of time to look further at the moment.
>
> I’m aware of this.  I took a brief look at upgrading to the latest jline
> but its a bit more work.  There is another sonatype version of jline that
> may work better in the short-term until moving to the official jline2 stuff
> can be done.
>
>
> 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.
>
Thanks, it's nice to simply use vs build, from my "user perspective" :-)



> Do you have interest in supporting further or prefer not to continue with
> it?
>
> I’ve recently put in a bit more effort to bring this stuff up to speed
> w/changes to maven.  I’m not sure I’ll be spending a ton of effort around
> it but I’m not sure how much effort is required.  Certainly though if folks
> are actually using this then I’ll do what I can to support its continued
> use.
>
Thanks - my curiosity was around if this was "abandon-ware" or you may make
it buildable again and do a few updates over the years... if not, then I
would keep looking for one!


There is another maven shell which may have more legs in terms of longer
> term community support, but I’m not yet sure where that is in terms of
> public availability.
>

Interesting, is it an internal Sonatype one or from somewhere else?

Re: Why no mvn daemon?

[Jason Dillon]

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

Re: Why no mvn daemon?

[Jason Dillon]

On March 8, 2016 at 7:45:53 AM, Jeff Jensen (jeffjen...@upstairstechnology.com) 
wrote:
FYI Just cloned and tried build but Jansi 1.2 is not in Central: "Could not 
find artifact org.fusesource.jansi:jansi:jar:1.2". 
http://search.maven.org/#search|gav|1|g%3A%22org.fusesource.jansi%22%20AND%20a%3A%22jansi%22
 

I noted the issue tracker no longer exists so replying here to start. 

jansi is not declared in the POMs, so assuming transitive. Found it is 
only referenced by 
"mvnsh-commands/mvnsh-maven/src/main/java/org/sonatype/maven/shell/commands/maven/ColorizingStream.java"
 
in mvnsh-commands/mvnsh-maven. 
I'm out of time to look further at the moment. 
I’m aware of this.  I took a brief look at upgrading to the latest jline but 
its a bit more work.  There is another sonatype version of jline that may work 
better in the short-term until moving to the official jline2 stuff can be done.



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.


Do you have interest in supporting further or prefer not to continue with 
it? 
I’ve recently put in a bit more effort to bring this stuff up to speed 
w/changes to maven.  I’m not sure I’ll be spending a ton of effort around it 
but I’m not sure how much effort is required.  Certainly though if folks are 
actually using this then I’ll do what I can to support its continued use.

There is another maven shell which may have more legs in terms of longer term 
community support, but I’m not yet sure where that is in terms of public 
availability.

—jason

Re: Why no mvn daemon?

[Jeff Jensen]

FYI Just cloned and tried build but Jansi 1.2 is not in Central: "Could not
find artifact org.fusesource.jansi:jansi:jar:1.2".
http://search.maven.org/#search|gav|1|g%3A%22org.fusesource.jansi%22%20AND%20a%3A%22jansi%22

I noted the issue tracker no longer exists so replying here to start.

jansi is not declared in the POMs, so assuming transitive.  Found it is
only referenced by
"mvnsh-commands/mvnsh-maven/src/main/java/org/sonatype/maven/shell/commands/maven/ColorizingStream.java"
in mvnsh-commands/mvnsh-maven.
I'm out of time to look further at the moment.

Jason, if you have a built version, do you mind adding it as a download to
the release files?
Do you have interest in supporting further or prefer not to continue with
it?


On Sat, Mar 5, 2016 at 10:40 PM, Jeff Jensen <
jeffjen...@upstairstechnology.com> wrote:

> Some months ago I was looking for something like this.  Due to this
> thread, I will soon set it up and try it.  (Thanks for sharing Tamás!)
>
>
> On Sat, Mar 5, 2016 at 10:31 PM, Jason Dillon 
> wrote:
>
>> On March 3, 2016 at 5:42:56 AM, Tamás Cservenák (ta...@cservenak.net)
>> wrote:
>> Maven Shell?
>>
>> https://github.com/jdillon/mvnsh
>>
>> Does anyone actually use this?
>>
>> —jason
>>
>>
>

Re: Why no mvn daemon?

[Jeff Jensen]

Some months ago I was looking for something like this.  Due to this thread,
I will soon set it up and try it.  (Thanks for sharing Tamás!)


On Sat, Mar 5, 2016 at 10:31 PM, Jason Dillon 
wrote:

> On March 3, 2016 at 5:42:56 AM, Tamás Cservenák (ta...@cservenak.net)
> wrote:
> Maven Shell?
>
> https://github.com/jdillon/mvnsh
>
> Does anyone actually use this?
>
> —jason
>
>

Re: Why no mvn daemon?

[Jason Dillon]

On March 3, 2016 at 5:42:56 AM, Tamás Cservenák (ta...@cservenak.net) wrote:
Maven Shell? 

https://github.com/jdillon/mvnsh 

Does anyone actually use this?

—jason

Re: Why no mvn daemon?

[Romain Manni-Bucau]

Good catch but something not changing user shell would be great and part of
maven distribution would be awesome.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Github  |
LinkedIn  | Tomitriber


2016-03-03 14:42 GMT+01:00 Tamás Cservenák :

> Maven Shell?
>
> https://github.com/jdillon/mvnsh
>
> On Thu, Mar 3, 2016 at 2:13 PM Romain Manni-Bucau 
> wrote:
>
> > Hi guys,
> >
> > Wonder why maven doesnt have any daemon and din't find anything
> satisfying
> > to answer this question with our preferred search engine.
> >
> > Idea would be - a bit like gradle I guess - to cache computations and
> > classloaders.
> >
> > Asking cause:
> > - computing the reactor could be long on big projects and if the pom
> didnt'
> > change between 2 builds it is useless
> > - creating a classloader can be long but "filling" it - loadClass -  is
> > really longer for several plugins - big classloaders or dynamic
> languages -
> > and doing it again and again is slow
> >
> > So the idea would be to run maven as a long running process
> (transparently
> > through a -D in mvn opts if possible) and:
> > - cache all is cacheable like the reactor etc while pom last modified
> date
> > didnt change (OS needs to support it or natives could be used for OS
> where
> > the JVM doesnt help)
> > - cache classloaders and reuse them when re-executing a mojo
> > - the communication between "mvn" which would then be a client to the
> > daemon could just use a socket
> >
> > Of course if the pom changed the cache would just be invaildated but we
> > would still gain the maven boot itself and we can still keep the
> > classloader cache for plugins while their configuration is the sae
> > (dependencies).
> >
> > Last thing missing in my description is two more configurations: a -Dxxx
> to
> > kill the daemon and one to skip it for one build.
> >
> > Any technical/politics reason I miss to not have it?
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Tomitriber
> > 
> >
>

Re: Why no mvn daemon?

[Tamás Cservenák]

Maven Shell?

https://github.com/jdillon/mvnsh

On Thu, Mar 3, 2016 at 2:13 PM Romain Manni-Bucau 
wrote:

> Hi guys,
>
> Wonder why maven doesnt have any daemon and din't find anything satisfying
> to answer this question with our preferred search engine.
>
> Idea would be - a bit like gradle I guess - to cache computations and
> classloaders.
>
> Asking cause:
> - computing the reactor could be long on big projects and if the pom didnt'
> change between 2 builds it is useless
> - creating a classloader can be long but "filling" it - loadClass -  is
> really longer for several plugins - big classloaders or dynamic languages -
> and doing it again and again is slow
>
> So the idea would be to run maven as a long running process (transparently
> through a -D in mvn opts if possible) and:
> - cache all is cacheable like the reactor etc while pom last modified date
> didnt change (OS needs to support it or natives could be used for OS where
> the JVM doesnt help)
> - cache classloaders and reuse them when re-executing a mojo
> - the communication between "mvn" which would then be a client to the
> daemon could just use a socket
>
> Of course if the pom changed the cache would just be invaildated but we
> would still gain the maven boot itself and we can still keep the
> classloader cache for plugins while their configuration is the sae
> (dependencies).
>
> Last thing missing in my description is two more configurations: a -Dxxx to
> kill the daemon and one to skip it for one build.
>
> Any technical/politics reason I miss to not have it?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Tomitriber
> 
>

Why no mvn daemon?

[Romain Manni-Bucau]

Hi guys,

Wonder why maven doesnt have any daemon and din't find anything satisfying
to answer this question with our preferred search engine.

Idea would be - a bit like gradle I guess - to cache computations and
classloaders.

Asking cause:
- computing the reactor could be long on big projects and if the pom didnt'
change between 2 builds it is useless
- creating a classloader can be long but "filling" it - loadClass -  is
really longer for several plugins - big classloaders or dynamic languages -
and doing it again and again is slow

So the idea would be to run maven as a long running process (transparently
through a -D in mvn opts if possible) and:
- cache all is cacheable like the reactor etc while pom last modified date
didnt change (OS needs to support it or natives could be used for OS where
the JVM doesnt help)
- cache classloaders and reuse them when re-executing a mojo
- the communication between "mvn" which would then be a client to the
daemon could just use a socket

Of course if the pom changed the cache would just be invaildated but we
would still gain the maven boot itself and we can still keep the
classloader cache for plugins while their configuration is the sae
(dependencies).

Last thing missing in my description is two more configurations: a -Dxxx to
kill the daemon and one to skip it for one build.

Any technical/politics reason I miss to not have it?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Github  |
LinkedIn  | Tomitriber