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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 < > [email protected]> 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 <[email protected]> > 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 < > [email protected]> wrote: > >> >> > Would beasting of tests be possible through gradle? > >> >> > > >> >> > On Sun, May 5, 2019 at 7:33 AM Mark Miller <[email protected]> > 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 < > [email protected]> 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 < > [email protected]> 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: [email protected] > >> >> For additional commands, e-mail: [email protected] > >> >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- - Mark http://about.me/markrmiller
