Hi Mark, > I find the Gradle way of doing things odd, but I knew better than to try and > go directly against them. > So none of this is really my choosing, I went with how you are supposed to do > it.
Nah -- that's not really right. Gradle is really flexible and there is no "convention" in my opinion. Everyone seems to do things their own way. What you mentioned perhaps results from this layering of build environment property shadowing: https://docs.gradle.org/current/userguide/build_environment.html What we deal with are two different categories of properties -- project properties (like tests.seed and other things affecting the build) and properties configuring gradle itself (like daemon-disabling, parallelisation, etc.). My concern lies with local configuration of the latter; messing with global gradle configuration affects any other project you're working on which is what I'm not comfortable with. > When it comes to allowing another prop file just for our project, I'm all for > it - just not the standard gradle.properties that is supposed to be committed > in a gradle project. It doesn't have to be committed nor is it needed in most cases. Just about the only exception is when you need to alter gradle itself -- increase the heap or force some other settings. Like here: https://github.com/elastic/elasticsearch/blob/master/gradle.properties For anything else you can use your own properties (read from anywhere you like) and layer them in any way you like. > You cannot override any settings from your gradle home file regardless, so > it's a little non intuitive - gradle home props rule all. Yes and that's exactly my concern. Even when you think of experimenting on different Lucene branches or having a "pristine" build -- a clean checkout should just work without you having to worry about any global overrides (in my opinion). A local non-versioned developer-only override file would work nicer here. > Anyway, I have exposed like one of our properties, so no, it's not thought > out or how it's going to be at all. Probably that property should be name > spaced beyond tests_jvms (translated from tests.jvms), They can be dot-separated and this works just fine. You need to be a bit more careful in groovy to quote it as a property but otherwise it'll work just fine. See the examples I committed yesterday for tests, for instance -Ptests.iters=5 > Sucking in a user prop file like we do with ant sounds great, just have to > get used to the fact that you cannot override your global settings. That's my point -- if we don't have to mess with global settings then we don't have to worry about it. Your "presets" task would still work like a charm but instead of modifying globals it'd modify local-non-versioned override file. This is easy to achieve (but you have to move them out from gradle.properties which is a higher-precedence level). > Anyway, I've never found it to be a problem. I didn't expect everyone would > customize our project settings in their gradle home file, I usually put stuff > there that I want to apply to all my checkouts (tests.jvms is actually one of > them), but all that is very individual. I think the configuration we have right now is incorrect in principle (the two different types of configuration settings I mentioned at the start are mixed). The daemon in particular already affected me (because I'd like to tweak build settings with the daemon for faster turnaround but at the same time not have it overridden globally). > But running tests within a module, or even running all modules tests, was no > good. You have solr-core tests coming late, you have many tests that pop up > from short runs to minutes+ (often tests with many sub class tests), and you > have a static JVM assignment for each test. So basically, it's easy to be > running long tests at the end of a run and use few JVM's, and with our tests, > this can be devastating. As for "soft" ordering of test tasks between modules you could try to configure cross-module task precedence with mustRunAfter (set it up programmatically)... this is a bit of an overkill but it'll ensure no tests run before the core tests are finished, for example. > We are a terrible case for gradles parallel tests. I read the issue history on their tracker. Indeed the situation could be improved. This is something we can work on later though, really. We can even switch the tests to an ant runner for now. The benefits of other cleanups are worth facing the tests problem. > So I started with solr-core generally taking 20+ minutes or more on my 18 > core machine, and with some other simple test taming, testFail can now do it > in just under 7 minutes. I haven't seen the implementation of this yet, but it's interesting. My general remark for the gradle build system switch would be that we try to make it simpler and easier... :) If you keep adding hardcore tweaks of gradle internal tasks (like you already do) then things will become hard to follow for others (like me) and you'll remain the only person who understands how it works. :) D. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
