> 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
