Hello from mvnd
Hi, as some of you may know already, Guillaume (cc'd) and me are working on a Daemon for Maven [1]. As with Gradle daemon, the main idea is to keep the JVM and the Maven plugins' code warm in a long living process so that during repeated builds the JIT-optimized code is available immediately. In addition to that, the builds are run with -T1C by default, there are some improvements in how the build progress is presented to the user and the `mvnd` command line client is a GraalVM native executable. Our main motivation to work on this was to make the building of our primary work projects faster. We work on Apache Camel, Camel Quarkus, Quarkus, etc. - all those are rather large projects with hundreds of Maven modules. I think we can say that the project left the PoC phase recently. We use it for our daily work, we made it available via SDKMAN and we are solving issues coming from the users. We'd like to contribute our code to Maven at some point when we believe that it is stable and battle tested enough. mvnd existed without mvn script for some time and therefore it could peacefully co-exist with stock Maven. Now it looks like we have to add our own mvn for reasons mentioned in https://github.com/mvndaemon/mvnd/pull/89 . Due to that, mvnd got some potential to clash with stock Maven when installed on the same machine. I am not especially happy about that and I wanted to assure the Maven community that we do it for technical reasons and that our ultimate aim is to contribute rather than hijack the ecosystem. Of course you are welcome to try mvnd and give feedback. Thanks, -- Peter [1] https://github.com/mvndaemon/mvnd - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Hello from mvnd
If an agreement between the projects can't be reached, have you considered renaming _your_ script to mvnc? On Tue, Oct 13, 2020 at 9:55 PM Peter Palaga wrote: > Hi, > > as some of you may know already, Guillaume (cc'd) and me are working on > a Daemon for Maven [1]. > > As with Gradle daemon, the main idea is to keep the JVM and the Maven > plugins' code warm in a long living process so that during repeated > builds the JIT-optimized code is available immediately. > > In addition to that, the builds are run with -T1C by default, there are > some improvements in how the build progress is presented to the user and > the `mvnd` command line client is a GraalVM native executable. > > Our main motivation to work on this was to make the building of our > primary work projects faster. We work on Apache Camel, Camel Quarkus, > Quarkus, etc. - all those are rather large projects with hundreds of > Maven modules. > > I think we can say that the project left the PoC phase recently. We use > it for our daily work, we made it available via SDKMAN and we are > solving issues coming from the users. > > We'd like to contribute our code to Maven at some point when we believe > that it is stable and battle tested enough. > > mvnd existed without mvn script for some time and therefore it could > peacefully co-exist with stock Maven. Now it looks like we have to add > our own mvn for reasons mentioned in > https://github.com/mvndaemon/mvnd/pull/89 . Due to that, mvnd got some > potential to clash with stock Maven when installed on the same machine. > I am not especially happy about that and I wanted to assure the Maven > community that we do it for technical reasons and that our ultimate aim > is to contribute rather than hijack the ecosystem. > > Of course you are welcome to try mvnd and give feedback. > > Thanks, > > -- Peter > > [1] https://github.com/mvndaemon/mvnd > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Hello from mvnd
Hi Andres, Our default executable is named mvnd. The reason for us to add the mvn script in our distribution is to make some plugins work. For example the IntegrationTestMojo from the maven-archetype-plugin is injected with a maven Invoker [1]. The default implementation will simply execute the $MAVEN_HOME/bin/mvn, so we need to provide one... Cheers, Guillaume Nodet [1] https://github.com/apache/maven-archetype/blob/maven-archetype-3.2.0/maven-archetype-plugin/src/main/java/org/apache/maven/archetype/mojos/IntegrationTestMojo.java#L142 > > Hi, > > as some of you may know already, Guillaume (cc'd) and me are working on > a Daemon for Maven [1]. > > As with Gradle daemon, the main idea is to keep the JVM and the Maven > plugins' code warm in a long living process so that during repeated > builds the JIT-optimized code is available immediately. > > In addition to that, the builds are run with -T1C by default, there are > some improvements in how the build progress is presented to the user and > the `mvnd` command line client is a GraalVM native executable. > > Our main motivation to work on this was to make the building of our > primary work projects faster. We work on Apache Camel, Camel Quarkus, > Quarkus, etc. - all those are rather large projects with hundreds of > Maven modules. > > I think we can say that the project left the PoC phase recently. We use > it for our daily work, we made it available via SDKMAN and we are > solving issues coming from the users. > > We'd like to contribute our code to Maven at some point when we believe > that it is stable and battle tested enough. > > mvnd existed without mvn script for some time and therefore it could > peacefully co-exist with stock Maven. Now it looks like we have to add > our own mvn for reasons mentioned in > https://github.com/mvndaemon/mvnd/pull/89 . Due to that, mvnd got some > potential to clash with stock Maven when installed on the same machine. > I am not especially happy about that and I wanted to assure the Maven > community that we do it for technical reasons and that our ultimate aim > is to contribute rather than hijack the ecosystem. > > Of course you are welcome to try mvnd and give feedback. > > Thanks, > > -- Peter > > [1] https://github.com/mvndaemon/mvnd > > -- Guillaume Nodet
Re: Hello from mvnd
I just wanna say kudos to mvnd - found it the other day on r/java (or r/programming) and I must say - this is awesome. It even plays well with our tiles-maven-plugin which I was sure it would play up on. Mark From: Peter Palaga Reply: Maven Developers List Date: 14 October 2020 at 8:55:14 AM To: dev@maven.apache.org Cc: Guillaume Nodet Subject: Hello from mvnd I think we can say that the project left the PoC phase recently. We use it for our daily work, we made it available via SDKMAN and we are solving issues coming from the users.
Re: Hello from mvnd
Hi, This one is not easy since both cases make sense IMHO (using "mvn" through mvnd or real pure isolated "mvn"). My immediate thought is to play with PATH order and to provide an "mvn" script as an extension of mvnd and not something built-in (well documented it is enough IMO). Using toolchain we can also make it more transparent (but not sure it would be the default without some enhancements and plugin upgrades which seems the issue you hit). Last thing I can think about is to relayout the distribution: mvnd/bin does not contain maven but set maven.home to a folder not in path with mvn script. This makes mvnd in PATH but not mvn script since a lot of mvn script lookup is done in mojo reading maven.home - if not it can/should be fixed since maven/bin does not have to be in PATH to work. Such "conflict" is very acceptable since it is exactly the goal of mvnd IMHO and it does not break OS setup. Hope it makes some sense. 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. 14 oct. 2020 à 01:02, Mark Derricutt a écrit : > I just wanna say kudos to mvnd - found it the other day on r/java (or > r/programming) and I must say - this is awesome. > > It even plays well with our tiles-maven-plugin which I was sure it would > play up on. > > Mark > > > > > From: Peter Palaga > Reply: Maven Developers List > Date: 14 October 2020 at 8:55:14 AM > To: dev@maven.apache.org > Cc: Guillaume Nodet > Subject: Hello from mvnd > > I think we can say that the project left the PoC phase recently. We use it > for our daily work, we made it available via SDKMAN and we are solving > issues coming from the users. >
Re: Hello from mvnd
On 14/10/2020 08:20, Romain Manni-Bucau wrote: Hi, This one is not easy since both cases make sense IMHO (using "mvn" through mvnd or real pure isolated "mvn"). My immediate thought is to play with PATH order and to provide an "mvn" script as an extension of mvnd and not something built-in (well documented it is enough IMO). Yeah, recommending users to put the stock Maven's bin before mvnd's was was what we were thinking about. The caveat is that e.g. SDKMAN iterates over packages in alphabetic order, prepending the individual bin folders to the PATH. mvnd/bin thus gets a higher precedence than maven/bin Using toolchain we can also make it more transparent (but not sure it would be the default without some enhancements and plugin upgrades which seems the issue you hit). Last thing I can think about is to relayout the distribution: mvnd/bin does not contain maven but set maven.home to a folder not in path with mvn script. That sounds viable, we should try that. Thanks for the idea! -- P This makes mvnd in PATH but not mvn script since a lot of mvn script lookup is done in mojo reading maven.home - if not it can/should be fixed since maven/bin does not have to be in PATH to work. Such "conflict" is very acceptable since it is exactly the goal of mvnd IMHO and it does not break OS setup. Hope it makes some sense. 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. 14 oct. 2020 à 01:02, Mark Derricutt a écrit : I just wanna say kudos to mvnd - found it the other day on r/java (or r/programming) and I must say - this is awesome. It even plays well with our tiles-maven-plugin which I was sure it would play up on. Mark From: Peter Palaga Reply: Maven Developers List Date: 14 October 2020 at 8:55:14 AM To: dev@maven.apache.org Cc: Guillaume Nodet Subject: Hello from mvnd I think we can say that the project left the PoC phase recently. We use it for our daily work, we made it available via SDKMAN and we are solving issues coming from the users. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Hello from mvnd
Le mer. 14 oct. 2020 à 10:20, Peter Palaga a écrit : > On 14/10/2020 08:20, Romain Manni-Bucau wrote: > > Hi, > > > > This one is not easy since both cases make sense IMHO (using "mvn" > through > > mvnd or real pure isolated "mvn"). > > My immediate thought is to play with PATH order and to provide an "mvn" > > script as an extension of mvnd and not something built-in (well > documented > > it is enough IMO). > > Yeah, recommending users to put the stock Maven's bin before mvnd's was > was what we were thinking about. The caveat is that e.g. SDKMAN iterates > over packages in alphabetic order, prepending the individual bin folders > to the PATH. mvnd/bin thus gets a higher precedence than maven/bin > Yeah but mvnd (script) manages the env it launches its process so it can modify/rewrite PATH at that moment. I'm not a big fan of such code cause it goes beyond the "launching" responsibility but it will make it work as you want and even enables the caller to decide which one wins (./mvnd --override-mvn ). > > > Using toolchain we can also make it more transparent (but not sure it > would > > be the default without some enhancements and plugin upgrades which seems > > the issue you hit). > > > > Last thing I can think about is to relayout the distribution: mvnd/bin > does > > not contain maven but set maven.home to a folder not in path with mvn > > script. > > That sounds viable, we should try that. Thanks for the idea! > > -- P > > > This makes mvnd in PATH but not mvn script since a lot of mvn script > lookup > > is done in mojo reading maven.home - if not it can/should be fixed since > > maven/bin does not have to be in PATH to work. Such "conflict" is very > > acceptable since it is exactly the goal of mvnd IMHO and it does not > break > > OS setup. > > > > Hope it makes some sense. > > > > 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. 14 oct. 2020 à 01:02, Mark Derricutt a écrit : > > > >> I just wanna say kudos to mvnd - found it the other day on r/java (or > >> r/programming) and I must say - this is awesome. > >> > >> It even plays well with our tiles-maven-plugin which I was sure it would > >> play up on. > >> > >> Mark > >> > >> > >> > >> > >> From: Peter Palaga > >> Reply: Maven Developers List < > dev@maven.apache.org> > >> Date: 14 October 2020 at 8:55:14 AM > >> To: dev@maven.apache.org > >> Cc: Guillaume Nodet > >> Subject: Hello from mvnd > >> > >> I think we can say that the project left the PoC phase recently. We use > it > >> for our daily work, we made it available via SDKMAN and we are solving > >> issues coming from the users. > >> > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Hello from mvnd
Re-layouting the mvnd distro worked indeed, see https://github.com/mvndaemon/mvnd/pull/96 . Many thanks for the suggestion, Romain! mvnd and stock Maven will be able to continue their peaceful co-existence :) -- P On 14/10/2020 10:20, Peter Palaga wrote: On 14/10/2020 08:20, Romain Manni-Bucau wrote: Hi, This one is not easy since both cases make sense IMHO (using "mvn" through mvnd or real pure isolated "mvn"). My immediate thought is to play with PATH order and to provide an "mvn" script as an extension of mvnd and not something built-in (well documented it is enough IMO). Yeah, recommending users to put the stock Maven's bin before mvnd's was was what we were thinking about. The caveat is that e.g. SDKMAN iterates over packages in alphabetic order, prepending the individual bin folders to the PATH. mvnd/bin thus gets a higher precedence than maven/bin Using toolchain we can also make it more transparent (but not sure it would be the default without some enhancements and plugin upgrades which seems the issue you hit). Last thing I can think about is to relayout the distribution: mvnd/bin does not contain maven but set maven.home to a folder not in path with mvn script. That sounds viable, we should try that. Thanks for the idea! -- P This makes mvnd in PATH but not mvn script since a lot of mvn script lookup is done in mojo reading maven.home - if not it can/should be fixed since maven/bin does not have to be in PATH to work. Such "conflict" is very acceptable since it is exactly the goal of mvnd IMHO and it does not break OS setup. Hope it makes some sense. 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. 14 oct. 2020 à 01:02, Mark Derricutt a écrit : I just wanna say kudos to mvnd - found it the other day on r/java (or r/programming) and I must say - this is awesome. It even plays well with our tiles-maven-plugin which I was sure it would play up on. Mark From: Peter Palaga Reply: Maven Developers List Date: 14 October 2020 at 8:55:14 AM To: dev@maven.apache.org Cc: Guillaume Nodet Subject: Hello from mvnd I think we can say that the project left the PoC phase recently. We use it for our daily work, we made it available via SDKMAN and we are solving issues coming from the users. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Hello from mvnd
Congrats guys! Can be worth some more noise cause I have to admit I didn't see mvnd before this thread and it is something all dev likely want to test "locally" (vs on a CI where you don't want it) IMHO. 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 ven. 16 oct. 2020 à 16:15, Peter Palaga a écrit : > Re-layouting the mvnd distro worked indeed, see > https://github.com/mvndaemon/mvnd/pull/96 . Many thanks for the > suggestion, Romain! > > mvnd and stock Maven will be able to continue their peaceful co-existence > :) > > -- P > > On 14/10/2020 10:20, Peter Palaga wrote: > > On 14/10/2020 08:20, Romain Manni-Bucau wrote: > >> Hi, > >> > >> This one is not easy since both cases make sense IMHO (using "mvn" > >> through > >> mvnd or real pure isolated "mvn"). > >> My immediate thought is to play with PATH order and to provide an "mvn" > >> script as an extension of mvnd and not something built-in (well > >> documented > >> it is enough IMO). > > > > Yeah, recommending users to put the stock Maven's bin before mvnd's was > > was what we were thinking about. The caveat is that e.g. SDKMAN iterates > > over packages in alphabetic order, prepending the individual bin folders > > to the PATH. mvnd/bin thus gets a higher precedence than maven/bin > > > >> Using toolchain we can also make it more transparent (but not sure it > >> would > >> be the default without some enhancements and plugin upgrades which seems > >> the issue you hit). > >> > >> Last thing I can think about is to relayout the distribution: mvnd/bin > >> does > >> not contain maven but set maven.home to a folder not in path with mvn > >> script. > > > > That sounds viable, we should try that. Thanks for the idea! > > > > -- P > > > >> This makes mvnd in PATH but not mvn script since a lot of mvn script > >> lookup > >> is done in mojo reading maven.home - if not it can/should be fixed since > >> maven/bin does not have to be in PATH to work. Such "conflict" is very > >> acceptable since it is exactly the goal of mvnd IMHO and it does not > >> break > >> OS setup. > >> > >> Hope it makes some sense. > >> > >> 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. 14 oct. 2020 à 01:02, Mark Derricutt a écrit > : > >> > >>> I just wanna say kudos to mvnd - found it the other day on r/java (or > >>> r/programming) and I must say - this is awesome. > >>> > >>> It even plays well with our tiles-maven-plugin which I was sure it > would > >>> play up on. > >>> > >>> Mark > >>> > >>> > >>> > >>> > >>> From: Peter Palaga > >>> Reply: Maven Developers List > >>> > >>> Date: 14 October 2020 at 8:55:14 AM > >>> To: dev@maven.apache.org > >>> Cc: Guillaume Nodet > >>> Subject: Hello from mvnd > >>> > >>> I think we can say that the project left the PoC phase recently. We > >>> use it > >>> for our daily work, we made it available via SDKMAN and we are solving > >>> issues coming from the users. > >>> > >> > > > >
Re: Hello from mvnd
On 16/10/2020 16:18, Romain Manni-Bucau wrote:
Congrats guys! Can be worth some more noise cause I have to admit I
didn't see mvnd before this thread and it is something all dev likely
want to test "locally" (vs on a CI where you don't want it) IMHO.
Yeah, mvnd definitely needs some battle-testing. More skilled hands
wanting to play with the code would be awesome too!
-- P
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 ven. 16 oct. 2020 à 16:15, Peter Palaga <mailto:ppal...@redhat.com>> a écrit :
Re-layouting the mvnd distro worked indeed, see
https://github.com/mvndaemon/mvnd/pull/96 . Many thanks for the
suggestion, Romain!
mvnd and stock Maven will be able to continue their peaceful
co-existence :)
-- P
On 14/10/2020 10:20, Peter Palaga wrote:
> On 14/10/2020 08:20, Romain Manni-Bucau wrote:
>> Hi,
>>
>> This one is not easy since both cases make sense IMHO (using "mvn"
>> through
>> mvnd or real pure isolated "mvn").
>> My immediate thought is to play with PATH order and to provide
an "mvn"
>> script as an extension of mvnd and not something built-in (well
>> documented
>> it is enough IMO).
>
> Yeah, recommending users to put the stock Maven's bin before
mvnd's was
> was what we were thinking about. The caveat is that e.g. SDKMAN
iterates
> over packages in alphabetic order, prepending the individual bin
folders
> to the PATH. mvnd/bin thus gets a higher precedence than maven/bin
>
>> Using toolchain we can also make it more transparent (but not
sure it
>> would
>> be the default without some enhancements and plugin upgrades
which seems
>> the issue you hit).
>>
>> Last thing I can think about is to relayout the distribution:
mvnd/bin
>> does
>> not contain maven but set maven.home to a folder not in path
with mvn
>> script.
>
> That sounds viable, we should try that. Thanks for the idea!
>
> -- P
>
>> This makes mvnd in PATH but not mvn script since a lot of mvn
script
>> lookup
>> is done in mojo reading maven.home - if not it can/should be
fixed since
>> maven/bin does not have to be in PATH to work. Such "conflict"
is very
>> acceptable since it is exactly the goal of mvnd IMHO and it does
not
>> break
>> OS setup.
>>
>> Hope it makes some sense.
>>
>> 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. 14 oct. 2020 à 01:02, Mark Derricutt mailto:m...@talios.com>> a écrit :
>>
>>> I just wanna say kudos to mvnd - found it the other day on
r/java (or
>>> r/programming) and I must say - this is awesome.
>>>
>>> It even plays well with our tiles-maven-plugin which I was sure
it would
>>> play up on.
>>>
>>> Mark
>>>
>>>
>>>
>>>
>>> From: Peter Palaga mailto:ppal...@redhat.com>> mailto:ppal...@redhat.com>>
>>> Reply: Maven Developers List mailto:dev@maven.apache.org>>
>>> mailto:dev@maven.apache.org>>
>>> Date: 14 October 2020 at 8:55:14 AM
>>> To: dev@maven.apache.org <mailto:dev@maven.apache.org>
mailto:dev@maven.apache.org>>
mailto:dev@maven.apache.org>>
>>> Cc: Guillaume Nodet mailto:gno...@redhat.com>> mailto:gno...@redhat.com>>
>>> Subject: Hello from mvnd
>>>
>>> I think we can say that the project left the PoC phase
recently. We
>>> use it
>>> for our daily work, we made it available via SDKMAN and we are
solving
>>> issues coming from the users.
>>>
>>
>
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
