lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject Re: Solr, gradle build and working with files compiled into the source tree
Date Tue, 03 Dec 2019 14:53:19 GMT
AFAIC, there’s no good reason whatsoever to preserve being able to run
from inside the source tree if it makes maintenance of the build system
harder. The current system grew organically over years and has its warts,
Preserving those warts just “so I can do what I’ve always done” is

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.

If I can rebuild Solr quickly after a small change, then the inconvenience
of having to change directories after a clean is minor. Very minor.

Unless I’m missing something about where the project gets built, let’s
keep it clean and nuke the “resolve” target and use the package directory.


> On Dec 3, 2019, at 4:05 AM, Dawid Weiss <> wrote:
> 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:
> 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:
> Dawid
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message