David asked this question regarding the gradle build and I think it may be a longer debate so I start a new thread:
> What gradlew command is the equivalent of "ant server" for Solr? I wish to > use "bin/solr". Here comes my very subjective opinion: let's get rid of the possibility to run various commands right on the source tree... Let me explain why. I had a *very* hard time even understanding what is where in the Solr source tree and whether it's versioned, compiled or generated. I ended up using a clean repository, compiled repository and a distribution ZIP and diffing against each other. This can't be a sane thing. Having compiled files in the source tree makes everything lousy - from complex rules in .gitignore files to extreme hacks inside build files (ant, gradle or otherwise) to make this copying and syncing work. What's the alternative? Well, one of such alternatives is a "packaging" project that puts together the binary project distribution. With gradle this is lighting fast, incremental and always correct (files are synced from source folders and dependencies -- they are not copied). For example, putting a Solr distribution from scratch takes 2 minutes on my machine (first run) but subsequent run (with no changes to anything) is nearly instantaneous (5 secs). If you remove a file or a dependency in the source and rebuild the package with: gradlew -p solr/packaging assemble then the assembled output under: solr/packaging/build/solr-9.0.0-SNAPSHOT will always have up-to-date state of a true distribution. You can run this gradle task from an IDE as well as part of a launch configuration and then start solr with a debugger so that it attaches right to your sources... The benefits of this are enormous. For instance you can shuffle source modules around and give them a more logical structure (the assembly takes care of where they're placed in the output). You can clearly see which components go where and how they're put together. Even now it's fairly clear how the distribution is put together, even if it's still not ideal: https://github.com/apache/lucene-solr/blob/gradle-master/solr/packaging/build.gradle#L50-L92 I realize it's hard to get people out of their comfort zone (I'm a prime example of this) but give this packaging thing a try, I don't think you'll be disappointed. This said, I did try to give people some backward compatibility with "resolve" target which copies over JARs to their previous source-tree locations... gradlew resolve I didn't verify it thoroughly though and the complexity of even trying to mimic the ant build here is hair-raising: https://github.com/apache/lucene-solr/blob/gradle-master/gradle/ant-compat/resolve.gradle Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
