maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: beam leaving maven, anything doable?
Date Tue, 28 Nov 2017 06:04:04 GMT
Le 27 nov. 2017 23:02, "Manfred Moser" <manfred@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" <igor@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 <michaelo@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-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >
>> > >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message