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 <markrmil...@gmail.com> wrote: > We can indeed make them work side by side. > > - Mark > > On Sun, May 5, 2019 at 11:36 AM Erick Erickson <erickerick...@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 <markrmil...@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 < >> ichattopadhy...@gmail.com> wrote: >> > Would beasting of tests be possible through gradle? >> > >> > On Sun, May 5, 2019 at 7:33 AM Mark Miller <markrmil...@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 <markrmil...@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 <caomanhdat...@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-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > > -- > - Mark > > http://about.me/markrmiller >
