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 Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn 2017-11-28 7:46 GMT+01:00 Hervé BOUTEMY <herve.bout...@free.fr>: >> 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 long time: having some common work on it would help > > Regards, > > Hervé > > Le mardi 28 novembre 2017, 07:04:04 CET Romain Manni-Bucau a écrit : >> Le 27 nov. 2017 23:02, "Manfred Moser" <manf...@simpligility.com> 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 thinks they will get significant improvements for their >> build times and they want to migrate.. let them. They will have to learn a >> whole bunch of different things and see some advantages as well as lot of >> disadvantages. >> >> >> They already have gradle build functional. >> >> >> >> From my perspective the build time is NOT significantly faster with Gradle >> and depends a LOT on what your build actually does. More importantly the >> integration with IDEs and other tools is a lot worse in many aspects. >> >> >> It is for multimoduke project. I didnt reproduce their figures but skipping >> their python part it is really like 30% faster for me for the same thg. >> >> >> >> As long as they can make sure that their binaries are published so that any >> user can easily consume them (e.a. they publish proper binaries and pom >> files to the Central Repository) I have no objection. >> >> Of course if they would step up and help us with Maven and make it better >> that would certainly be better than putting effort into migrating... but >> thats a different story. >> >> And another one of course is that Gradle is open source project mostly >> sponsored by a single company and hence under a very different control >> compared to Maven.. >> >> >> >> Agree bit /2 - for most other people - the build time which is significant >> (it is not a commmons project you can build in less than 5mn ;)). >> >> With so much difference I strongly think there are room for improvement but >> fail to see how maven graph computation can look that bad :(. >> >> >> Manfred >> >> Romain Manni-Bucau wrote on 2017-11-27 13:43: >> > Doesnt change anything significative - this is my setup. >> > >> > Le 27 nov. 2017 22:01, "Igor Fedorenko" <i...@ifedorenko.com> 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 local repository is used from single-process >> >> multi-threaded build. >> >> >> >> [1] https://github.com/takari/takari-local-repository/issues/4 >> >> [2] https://github.com/takari/takari-local-repository/issues/5 >> >> >> >> -- >> >> Regards, >> >> Igor >> >> >> >> On Mon, Nov 27, 2017, at 03:28 PM, Michael Osipov wrote: >> >> > 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 >> >> >> > > drawback of maven it seems. >> >> > > >> >> > > Romain Manni-Bucau >> >> > > @rmannibucau | Blog | Old Blog | Github | LinkedIn >> >> > > >> >> > > 2017-11-27 20:47 GMT+01:00 Michael Osipov <micha...@apache.org>: >> >> > >> 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. >> >> > >>> >> >> > >>> [1] >> >> > >>> https://lists.apache.org/thread.html/6d6f7ffc66622db1dd459e1704c3a5 >> >> >> >> d8a4bc29c2d9c0b60354fd3b6a@%3Cdev.beam.apache.org%3E >> >> >> >> > >> Did they disable the build daemon? If not, it is not a fair >> >> >> >> comparsion. >> >> >> >> > >> Michael >> >> > > >> >> > > --------------------------------------------------------------------- >> >> > > 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 >> >> >> >> --------------------------------------------------------------------- >> >> 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 > > > > --------------------------------------------------------------------- > 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
