> Switching to gradle means deleting tons of crap - all sorts of work arounds > and ant abuse go away.
True. But other things will creep in. Take a look at any larger gradle build -- there's lots of groovy-code magic in there... To be clear: I do think the switch over to gradle is worth it (for the reasons you mentioned, if not anything else). Dawid On Mon, May 6, 2019 at 8:03 AM Mark Miller <[email protected]> wrote: > > I don't know that we need or want to do side by side, it's just doable. If we > did do that, certainly the goal would be to keep it short. Whatever keeps > people from pulling the rug out from under me if I work on this further. > > Any other bike-shedding to be done or major concerns? > > This really will be a lot of work - one of those the last 20% takes 80% of > the time type things. > > Please, please, please, stop me now. > > - Mark > > > On Sun, May 5, 2019 at 11:39 PM David Smiley <[email protected]> wrote: >> >> I agree that an easier-to-understand build is an important virtue we should >> try to achieve here (for the reasons you mentioned). Our build is too >> complex and non-standard. Any other benefits are icing on the cake. >> >> RE "side by side"; that could weigh us down maintaining more; I hope this >> isn't long term. >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> On Sun, May 5, 2019 at 6:23 PM Mark Miller <[email protected]> wrote: >>> >>> We can indeed make them work side by side. >>> >>> - Mark >>> >>> On Sun, May 5, 2019 at 11:36 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] >>>> >>> >>> >>> -- >>> - Mark >>> >>> http://about.me/markrmiller > > > > -- > - Mark > > http://about.me/markrmiller --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
