beam leaving maven, anything doable?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

beam leaving maven, anything doable?

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/6d6f7ffc66622db1dd459e1704c3a5d8a4bc29c2d9c0b60354fd3b6a@%3Cdev.beam.apache.org%3E

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: beam leaving maven, anything doable?

michaelo
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 <[hidden email]>:
>> 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/6d6f7ffc66622db1dd459e1704c3a5d8a4bc29c2d9c0b60354fd3b6a@%3Cdev.beam.apache.org%3E
>>
>>
>> Did they disable the build daemon? If not, it is not a fair comparsion.
>>
>> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: beam leaving maven, anything doable?

Romain Manni-Bucau
Le 27 nov. 2017 23:02, "Manfred Moser" <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>:
>> > >> 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: [hidden email]
>> > > For additional commands, e-mail: [hidden email]
>> > >
>> > >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]