On Tue, 28 Nov 2017 07:46:07 +0100, Hervé BOUTEMY <herve.bout...@free.fr> 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 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

Yes, I agree on this one. I talked with Arnaud about adding several hooks/extensionpoints/... in Maven for easier support by CI servers (just like M3.0 was an architectural update for better support by IDEs).
Knowing the time per execution-block is interesting info.
That might include being able to capture MojoExceptions, so the evil jenkins-maven-plugin doesn't have to change the configuration of surefire at runtime. And it might help MINVOKER-229.

Robert


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

Reply via email to