Re: beam leaving maven, anything doable?

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

Re: beam leaving maven, anything doable?

michaelo
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]

Reply | Threaded
Open this post in threaded view
|

Re: beam leaving maven, anything doable?

Igor Fedorenko-3
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/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]
>

---------------------------------------------------------------------
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
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]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: beam leaving maven, anything doable?

Hervé BOUTEMY
In reply to this post by michaelo
> 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]