It's a trade-off; let's acknowledge that the current system has its benefits. For example not needing to change to some other directory to run Solr. Some in-place changes (e.g. to bin/solr) are possible without additional sync steps. And at present the gradle assemble script will use a target path with a version in the name which may make docs/instructions/scripts and habits more susceptible to getting out of date / being wrong. That could be fixed easily though.
Thanks for doing "gradlew resolve". "resolve" is not in my muscle memory; "server" is, but seems similar. Maybe some small changes could make "graldew resolve" more straightforward. Despite you and Erick not liking it, I like that you've hid it away in one place and it doesn't look hideous to me. Any way there is no hurry on this matter; it doesn't block merging or adopting the gradle build. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Tue, Dec 3, 2019 at 12:39 PM Dawid Weiss <[email protected]> wrote: > > I’d favor taking out the “resolve” task as well. Thanks for considering > it, > > but let’s keep things architecturally sound and add back complexity only > > when necessary. > > That entire folder is meant to be discarded at some point. Let's allow > it to sit there for a bit though, > doesn't do any harm and we'll see how the transition goes. > > D. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
