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
