lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dawid Weiss <dawid.we...@gmail.com>
Subject Re: Call for help: moving from ant build to gradle
Date Sun, 05 May 2019 19:13:08 GMT
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


Mime
View raw message