Re: beam leaving maven, anything doable?

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

Re: beam leaving maven, anything doable?

Romain Manni-Bucau
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 <[hidden email]>:

>> 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" <[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]
>
>
>
> ---------------------------------------------------------------------
> 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?

Robert Scholte-8
On Tue, 28 Nov 2017 07:46:07 +0100, Hervé BOUTEMY <[hidden email]>  
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" <[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]
>
>
>
> ---------------------------------------------------------------------
> 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]