> 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
