Hello from mvnd

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Hello from mvnd

Peter Palaga
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Hello from mvnd

Mark Derricutt
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 <[hidden email]> <[hidden email]>
Reply: Maven Developers List <[hidden email]> <[hidden email]>
Date: 14 October 2020 at 8:55:14 AM
To: [hidden email] <[hidden email]> <[hidden email]>
Cc: Guillaume Nodet <[hidden email]> <[hidden email]>
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.
Reply | Threaded
Open this post in threaded view
|

Re: Hello from mvnd

Peter Palaga
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 <[hidden email]> 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 <[hidden email]> <[hidden email]>
>> Reply: Maven Developers List <[hidden email]> <[hidden email]>
>> Date: 14 October 2020 at 8:55:14 AM
>> To: [hidden email] <[hidden email]> <[hidden email]>
>> Cc: Guillaume Nodet <[hidden email]> <[hidden email]>
>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Hello from mvnd

Peter Palaga
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 <[hidden email]
> <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>> <[hidden email]
>     <mailto:[hidden email]>>
>      >>> Reply: Maven Developers List <[hidden email]
>     <mailto:[hidden email]>>
>      >>> <[hidden email] <mailto:[hidden email]>>
>      >>> Date: 14 October 2020 at 8:55:14 AM
>      >>> To: [hidden email] <mailto:[hidden email]>
>     <[hidden email] <mailto:[hidden email]>>
>     <[hidden email] <mailto:[hidden email]>>
>      >>> Cc: Guillaume Nodet <[hidden email]
>     <mailto:[hidden email]>> <[hidden email]
>     <mailto:[hidden email]>>
>      >>> 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: [hidden email]
For additional commands, e-mail: [hidden email]