lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: Call for help: moving from ant build to gradle
Date Sun, 05 May 2019 20:43:38 GMT
I'm not particularly moved by any performance differences. And the gradle
daemon is not my friend.

I see the main benefits of gradle as:

Our current ant+ivy+maven system is an insanely complicated Frankenstein.
It's high barrier of entry for new devs and does our project a disservice.
Adding or changing things is painful. The maven shadow build is painful.

Switching to gradle means deleting tons of crap - all sorts of work arounds
and ant abuse go away.

gradle can be configured to do auto version resolution in a sensable way
for us - when done right, this is a large improvement over devs resolving
version conflicts on their own, ad hoc.

- Mark



On Sun, May 5, 2019 at 2:13 PM Dawid Weiss <dawid.weiss@gmail.com> wrote:

> Sure, maybe. My feelings towards Gradle range from love to fury (and
> quite frequently in short time spans). For example I'm sort of
> wondering what will happen to those build machines (which aren't
> exactly speed beasts) when you launch multiple builds on different
> JVMs; gradle is fast once it has an up-to-date daemon... but leaving
> stray processes behind on a CI machine is going to hurt sooner or
> later.
>
> Don't get me wrong -- I like gradle, really. But I've had enough "wtf"
> moments with it not to be too excited either. :)
>
> Dawid
>
> On Sun, May 5, 2019 at 8:50 PM Varun Thacker <varun@vthacker.in> wrote:
> >
> > I think you're right on the tests part.
> >
> > Task that are run by the QA Bot (
> https://issues.apache.org/jira/browse/SOLR-13049?focusedCommentId=16832997&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16832997
> ) could benefit from caching though right?
> >
> > On Sun, May 5, 2019 at 11:39 AM Dawid Weiss <dawid.weiss@gmail.com>
> wrote:
> >>
> >> I think most of the build time is spent in tests. Since we're using
> >> randomization I don't think you'd gain much from caches?
> >>
> >> Dawid
> >>
> >> On Sun, May 5, 2019 at 8:24 PM Varun Thacker <varun@vthacker.in> wrote:
> >> >
> >> > Over the last few months, I've realized the power of build caches.
> >> >
> >> > In the future could we have remote caches for Jenkins? In which case
> the Lucene/Solr QA bot will be significantly faster as well? And then it
> could just run against all patches and even block commits that violate it?
> >> >
> >> > On Sun, May 5, 2019 at 9:37 AM Erick Erickson <
> erickerickson@gmail.com> wrote:
> >> >>
> >> >> I don’t know enough about the differences to even think consider
> complaining.
> >> >>
> >> >> Is the proposal that we use Gradle for master and continue to use
> ant for 8x? As long as the two build systems can exist side by side (i.e.
> we can build master by executing some Gradle target and continue to build
> 8x with Ant like we always have) the minor inconvenience doesn’t merit
> standing in the way of progress.
> >> >>
> >> >> If that’s the case I don’t particularly care if we continue to
use
> Ant with 8x forever. Or maybe some ambitious person can work on bringing 8x
> to Gradle after it has some mileage on master.
> >> >>
> >> >> And I have great faith that you wouldn’t be putting in the work
> unless you thought it was worth it ;)
> >> >>
> >> >> Erick
> >> >>
> >> >> > On May 4, 2019, at 10:31 PM, Mark Miller <markrmiller@gmail.com>
> wrote:
> >> >> >
> >> >> > We already dump out to groovy to do anything interesting, so I
> doubt there is much we can't replicate.
> >> >> >
> >> >> > - Mark
> >> >> >
> >> >> > On Sat, May 4, 2019 at 9:09 PM Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
> >> >> > Would beasting of tests be possible through gradle?
> >> >> >
> >> >> > On Sun, May 5, 2019 at 7:33 AM Mark Miller <markrmiller@gmail.com>
> wrote:
> >> >> > >
> >> >> > > I looked into this a little more.
> >> >> > >
> >> >> > > Seems if we just do it with master and going forward, we
don’t
> need multi version support - Uwe seems to have taken it out with the move
> to Java 11?
> >> >> > >
> >> >> > > I can handle regenerate.
> >> >> > >
> >> >> > > The other quality checks shouldn’t be crazy.
> >> >> > >
> >> >> > > So I guess we can probably do this, but before I focus on
BS
> details, please speak up if you hate the idea of Gradle and you have the
> clout to stop it.
> >> >> > >
> >> >> > >
> >> >> > > Mark
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > On Sat, May 4, 2019 at 5:56 PM Mark Miller <
> markrmiller@gmail.com> wrote:
> >> >> > >>
> >> >> > >> I've got my own lucene-solr gradle branch as well.
> >> >> > >>
> >> >> > >> I stole the BuildPlugin and CheckWorkingCopy from Dat's
branch,
> but also made some changes.
> >> >> > >>
> >> >> > >> * Similar to above above, I don't move the src files
so it can
> keep things up to date without lots of pain.
> >> >> > >> * I used a plugin that lets us define versions in a root
props
> file like we currently do and ensures we use the same versions in all
> modules even after auto conflict resolution (unlike gradle by default)
> >> >> > >> * It also locks versions so we can continue to pay attention
to
> scary automatic dependency resolution changes
> >> >> > >> * implementation and api used instead of compile
> >> >> > >> * Things build and the majority of tests pass (Lucene's
> TestVirtualMethod does not for example)
> >> >> > >>
> >> >> > >> If someone like Uwe is serious about helping out with
fun
> extras (regenerating sources, extracting data from ICU, quality checks,
> documentation (XSLT)), I'd look at contributing.
> >> >> > >>
> >> >> > >> - Mark
> >> >> > >>
> >> >> > >>
> >> >> > >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh <
> caomanhdat317@gmail.com> wrote:
> >> >> > >>>
> >> >> > >>> Cool Diego,
> >> >> > >>>
> >> >> > >>> I will take a look on this. Thanks a lot!
> >> >> > >>
> >> >> > >>
> >> >> > >>
> >> >> > >> --
> >> >> > >> - Mark
> >> >> > >>
> >> >> > >> http://about.me/markrmiller
> >> >> > >
> >> >> > > --
> >> >> > > - Mark
> >> >> > >
> >> >> > > http://about.me/markrmiller
> >> >> >
> >> >> >
> >> >> > --
> >> >> > - Mark
> >> >> >
> >> >> > http://about.me/markrmiller
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

-- 
- Mark

http://about.me/markrmiller

Mime
View raw message