Re: beam leaving maven, anything doable?

2017-11-29 Thread Robert Scholte
On Tue, 28 Nov 2017 07:46:07 +0100, Hervé BOUTEMY wrote: With so much difference I strongly think there are room for improvement but fail to see how maven graph computation can look that bad :(. IMHO, visualizing that graph and the effective time on each build step

Re: beam leaving maven, anything doable?

2017-11-27 Thread Romain Manni-Bucau
if you browse the beam discussion you have most of figures. Using beam can be nice - even if personally I would have loved tomee indeed ;) - since we know we can boost it a lot upfront. let me know if you need help Hervé, I would be happy to solve it before they vote the switch. Romain

Re: beam leaving maven, anything doable?

2017-11-27 Thread Hervé BOUTEMY
> With so much difference I strongly think there are room for improvement but > fail to see how maven graph computation can look that bad :(. IMHO, visualizing that graph and the effective time on each build step is the first thing to do before trying to change anything It's on my TODO list for a

Re: beam leaving maven, anything doable?

2017-11-27 Thread Romain Manni-Bucau
Le 27 nov. 2017 23:02, "Manfred Moser" a écrit : Just my 2c as a long terms Maven user and committer.. People have been moving from one build tool the other for years. That includes to Gradle, to Maven and to all sorts of others stuff and back. If the Beam project

Re: beam leaving maven, anything doable?

2017-11-27 Thread Manfred Moser
Just my 2c as a long terms Maven user and committer.. People have been moving from one build tool the other for years. That includes to Gradle, to Maven and to all sorts of others stuff and back. If the Beam project thinks they will get significant improvements for their build times and they

Re: beam leaving maven, anything doable?

2017-11-27 Thread Romain Manni-Bucau
Doesnt change anything significative - this is my setup. Le 27 nov. 2017 22:01, "Igor Fedorenko" a écrit : > I wouldn't bother with Takari local repository, it's broken broken, see > [1] and [2]. Default Aether local repository impl is thread-safe enough, > at least when

Re: beam leaving maven, anything doable?

2017-11-27 Thread Igor Fedorenko
I wouldn't bother with Takari local repository, it's broken broken, see [1] and [2]. Default Aether local repository impl is thread-safe enough, at least when local repository is used from single-process multi-threaded build. [1] https://github.com/takari/takari-local-repository/issues/4 [2]

Re: beam leaving maven, anything doable?

2017-11-27 Thread Michael Osipov
I really would like to see the same numbers with Takari Smart Builder and thread-safe local repo module. Am 2017-11-27 um 20:52 schrieb Romain Manni-Bucau: Even doing it the difference is significative. The parallelism and graph computation (linked to the local repo thread safety) is the main

Re: beam leaving maven, anything doable?

2017-11-27 Thread Romain Manni-Bucau
Even doing it the difference is significative. The parallelism and graph computation (linked to the local repo thread safety) is the main drawback of maven it seems. Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn 2017-11-27 20:47 GMT+01:00 Michael Osipov

Re: beam leaving maven, anything doable?

2017-11-27 Thread Michael Osipov
Am 2017-11-27 um 20:24 schrieb Romain Manni-Bucau: Hi guys, anything doable on maven side (either tuning or code changes) to be as good as gradle on beam project. The project is goind to leave maven as build tool ([1]) and I think it is very bad for 1. the community and 2. ASF as an ecosystem.

beam leaving maven, anything doable?

2017-11-27 Thread Romain Manni-Bucau
Hi guys, anything doable on maven side (either tuning or code changes) to be as good as gradle on beam project. The project is goind to leave maven as build tool ([1]) and I think it is very bad for 1. the community and 2. ASF as an ecosystem. [1]