I would start by looking at this: https://docs.gradle.org/current/userguide/application_plugin.html?
On Sat, Nov 16, 2019 at 5:02 PM Erick Erickson <erickerick...@gmail.com> wrote: > > Hmmm, I’ll have to start looking at this then. There may be two separate > issues here: > > 1> for developers, a convenient way to just compile-and-go, i.e. starting a > Solr instance after a build. I certainly won’t attempt to insist that I can > do it the same way we did in the Ant world if there’s a better “gradle way”, > and it sounds like there is. > > 2> The packageDist task seems incomplete given that when I tried that and > unpacked the tarball, the usual way to start Solr was missing (no > solr/bin/solr script to be specific). > > <1> is more important IMO short term if we’re going to try to get people to > kick the tires in their daily work, <2> is a blocker before cutting over > completely some time in the future. > > And I’ll happily take a break from this and see if I can figure out why the > ant test fails for TestKoreanTokenizer. That’s what I was trying to do when I > got sidetracked. Figured “Well, let’s merge things from master just to > eliminate that possibility” and all hell broke loose. > > Thanks again, > Erick > > > > > On Nov 16, 2019, at 2:02 PM, Dawid Weiss <dawid.we...@gmail.com> wrote: > > > >> I’ve really got to disagree here when it comes to Solr. I dive into and > >> out of building/running Solr many times a day. Having to package it all up > >> then explode it just to check something and/or explore a problem is a > >> waste. > > > > It's not really like this. With gradle you can set up a packaging > > folder (under build/) so that it is synced with any required resources > > (and this is done only if necessary, incrementally). Creating a > > compressed package is just the finalizing step from that location. All > > this is lighting fast. > > > > I don't want to fight people who work with Solr -- I don't do much > > development with Solr these days and like I said I don't even > > understand why there are so many different "packaging" ant tasks and > > what they actually do. My experience just tells me that keeping build > > files mixed with source locations is not really convenient. Gradle > > solves it in an elegant way (but sure - it's a subjective point of > > view). > > > >> And at this point I don’t see how to start Solr at all. Even if I execute > >> the “packageDist” task and produce a tgz and zip file, when those are > >> exploded the ../solr/bin directory isn’t there, so no ../solr/bin/solr > >> script to start an instance etc. > > > > I'll take a look at it this weekend, Erick, but you need to give me some > > time. > > > >> Going through the cycle of having to package it up and explode it just to > >> do that is unacceptable. > > > > I need to take a look at the branch status vs. master first (vide your > > remarks about tests failing). Then I need to understand how to package > > Solr (from the various bits of ant code) and finally write this in > > gradle. I'll let you know how far I can get this over the weekend. > > > > Dawid > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
