That's against Gradle best practices, if you look it up, this is the way Gradle is intended to work. Settings like
That task description can warn about editing your file, but I feel it's pretty safe given that you have to decide to use it. We don't remove anything and we don't change controversial settings (unless they break us, like configure on demand). Settings like org.gradle.workers.max are used by the Daemon and meant to be pretty universal as Daemons are intended to be reused. Another property is ours - if you have overridden it, asking for these settings changes will change it. Good? Configure on demand will break us and is experimental and is noted around a variety of bugs, so we disable it. Sure, just smashing up someones ~/.gradle/gradle.properties is not nice, but making required and performance adjustments at request seems great to me. - Mark On Sun, Sep 15, 2019 at 10:56 PM Gus Heck <gus.h...@gmail.com> wrote: > Haven't looked at your code, but it sounds a bit scary for you (or > whomever comes after you) to touch my ~/.gradle/gradle.properties. > Sometimes I have some pretty important stuff there.... Can we use the > project specific gradle.properties in the project root dir and make it > .gitignore? > > On Sun, Sep 15, 2019 at 8:47 PM Mark Miller <markrmil...@gmail.com> wrote: > >> Okay, there is now a task called defaultUserConfig >> >> You can do gw defaultUserConfig to set some recommended settings in >> ~/.gradle/gradle.properties. By default they should be more relaxed, but we >> can tune as needed. >> >> For better build performance but also more resource usage you can do: >> >> gw defaultUserConfig --style=aggressive >> >> Mark >> >> On Sun, Sep 15, 2019 at 5:50 PM Mark Miller <markrmil...@gmail.com> >> wrote: >> >>> By the way, I did hear about the hack day and some Gradle testing, which >>> is great, and very useful. Totally needed, but we also need a bit of a more >>> deep core developer view of things vs the old build as well. The type of >>> stuff that’s much harder to tease out than verifying all the new build >>> targets and such. Of course a lot of that can come after we switch, but I >>> have a sneaky feeling some core devs will have deep opinions about certain >>> things. >>> >>> Ill add a new task for default config setup. >>> >>> Mark >>> >>> On Sun, Sep 15, 2019 at 5:12 PM Mark Miller <markrmil...@gmail.com> >>> wrote: >>> >>>> I'll just detail it out here as well: >>>> >>>> You can configure parallelism in ~/.gradle/gradle.properties >>>> >>>> org.gradle.workers.max=2 >>>> tests_jvms=5 >>>> >>>> org.gradle.workers.max is controlled by gradle and defaults to the >>>> number of cores detected - I wish I could change to divided by 2. >>>> test_jvms is controlled by us and defaults to the number of cores >>>> detected / 2. >>>> >>>> org.gradle.workers.max controls the total number of jvms that will be >>>> run in parallel - for tasks or tests or whatever gradle is doing. >>>> test_jvms controls how many parallel jvms a module will use for tests, >>>> but that is also limited by org.gradle.workers.max >>>> >>>> You should try setting both to cores / 2 and work down from there if >>>> needed. >>>> >>>> When running tests across multiple modules, org.gradle.workers.max is >>>> the actual limit for test jvms spun up because each module is only limited >>>> to test_jvms, but ALL tasks are limited to org.gradle.workers.max and >>>> module tasks are run in parallel by default. >>>> >>>> By setting them the same, we get similar behavior whether we run tests >>>> from the root directory of the project (all tests) or from a single module >>>> (say solr-core). >>>> >>>> On Sun, Sep 15, 2019 at 5:03 PM Mark Miller <markrmil...@gmail.com> >>>> wrote: >>>> >>>>> I've added more about that here: >>>>> https://cwiki.apache.org/confluence/display/SOLR/Intro+to+the+Gradle+build >>>>> >>>>> It's configurable, but difficult for us to choose a default based on >>>>> cores as far as I can tell and gradles default, which is based on cores >>>>> detected, is too high, especially because of hyperthreading. >>>>> >>>>> Probably the best we can do is default it to a hard 2 or 4 and let >>>>> people raise it depending on what wait you want to error. In both cases >>>>> the >>>>> majority of people will want to change it. >>>>> >>>>> On Sun, Sep 15, 2019 at 3:39 PM Gus Heck <gus.h...@gmail.com> wrote: >>>>> >>>>>> Not sure if you heard, but about a half a dozen folks tried it out on >>>>>> macs and one on windows at the hack day on Tuesday before Activate. It >>>>>> caused some scrambling for sharing of power bricks (a single run of the >>>>>> tests eats 70% of a fully charged 2018 macbook pro battery in 45 min), >>>>>> but >>>>>> the good news is it only failed on well known flaky tests and on the one >>>>>> windows machine and that in the PDF building for the ref guide (and there >>>>>> was that small bit with the error message and the AtomicBoolean that I >>>>>> fixed). I've heard some opinions that maybe we don't need the PDF version >>>>>> in the future, The one bit of feedback that came out of it was it would >>>>>> be >>>>>> nice to have a task that tweaked the configs things to not peg the >>>>>> processor quite so efficiently :). Certainly we do want the mode for full >>>>>> utilization to be available, but a background mode would be good too in >>>>>> case folks need to do other work. >>>>>> >>>>>> -Gus >>>>>> >>>>>> On Sun, Sep 15, 2019 at 3:24 PM Mark Miller <markrmil...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Okay, I've tried to spread that link a little on social media as >>>>>>> well. >>>>>>> >>>>>>> Please do some experimentation. Especially those of you that use or >>>>>>> know more esoteric things about the build. The basics are pretty solid, >>>>>>> most have been working for months now, it's the corners and crannies >>>>>>> that >>>>>>> I'm more concerned about. You could have built and run tests a few >>>>>>> months >>>>>>> ago and said, nice, it's working, but then I've done 10,000 things since >>>>>>> then that were necessary. You may easily not realize things are a >>>>>>> problem >>>>>>> until you really dig into something. >>>>>>> >>>>>>> The more that devs can start trying out Gradle now, the less overlap >>>>>>> of the two build systems we will need. >>>>>>> >>>>>>> The idea of the overlap is that it will almost force many of us to >>>>>>> start trying things out - at which point we will start to understand any >>>>>>> key things that are missing, key problems or bugs, etc. If I just make >>>>>>> the >>>>>>> switch and let the cards fall were they may, those cards are almost >>>>>>> certainly going to be very disruptive and annoying to a lot of people. >>>>>>> >>>>>>> It will also give us a chance to start rolling CI and other tools >>>>>>> over to using the Gradle build while ant+ivy are still available and in >>>>>>> charge. I don't think it's a great idea to try and do this all at one >>>>>>> moment, that will be difficult to coordinate and be more disruptive to >>>>>>> less >>>>>>> interested devs. We would like to keep the dual build situation >>>>>>> contained >>>>>>> and short though. That's why I have a plan to pull out if we don't make >>>>>>> enough progress by a month or twos time (closer to a month). >>>>>>> >>>>>>> If we have enough experimentation ahead of time, the overlap can be >>>>>>> very short - we start moving things like jenkins jobs over and when we >>>>>>> are >>>>>>> done and confident the world is not ending, we make some adjustments so >>>>>>> that gradle owns the build (eg the dependency tree) and then remove >>>>>>> ant+ivy+maven. >>>>>>> >>>>>>> Some things like the smoke tester and what not *can* come shortly >>>>>>> after we switch I think - we have until the 9 release to truly get >>>>>>> everything in order (keeping in mind that we are still developing so >>>>>>> some >>>>>>> things are still critical). But we need CI and other basics all moved >>>>>>> over >>>>>>> when we flip the ownership switch. >>>>>>> >>>>>>> - Mark >>>>>>> >>>>>>> On Sun, Sep 15, 2019 at 12:28 PM Mark Miller <markrmil...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> I've started to put together a little guide to help people ramp up >>>>>>>> here: >>>>>>>> https://cwiki.apache.org/confluence/display/SOLR/Intro+to+the+Gradle+build >>>>>>>> >>>>>>>> On Sat, Sep 14, 2019 at 9:09 PM Mark Miller <markrmil...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> https://issues.apache.org/jira/browse/SOLR-13452 >>>>>>>>> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to >>>>>>>>> Gradle. >>>>>>>>> >>>>>>>>> Hey all. >>>>>>>>> >>>>>>>>> Here is my Lucene and Solr 'move to Gradle' plans. >>>>>>>>> >>>>>>>>> * I plan on trying to commit the Gradle build by 9/30 >>>>>>>>> * In the meantime I'll do a bit more work on packaging, >>>>>>>>> publishing, and dependencies. >>>>>>>>> * It would be great if others could start digging in a bit as well. >>>>>>>>> * I plan to try and sidecar Gradle to begin with. Once that >>>>>>>>> happens, I really need others to start digging in as we have a lot to >>>>>>>>> do >>>>>>>>> (switch ci and other tools to the new build, figure out new release >>>>>>>>> docs >>>>>>>>> and issues, finish the Solr documentation module (I'll try and get to >>>>>>>>> that >>>>>>>>> earlier than later), and generally make things pleasant across as >>>>>>>>> many dev >>>>>>>>> envs as we can. >>>>>>>>> * Beyond that, there will likely be a longer tail of smaller >>>>>>>>> issues or missing things even after we make the switch. >>>>>>>>> * I'll put some effort into the side car experiment for another >>>>>>>>> month or two perhaps (maybe not much in November) >>>>>>>>> * If things are not looking like we will be able to flip the >>>>>>>>> switch, I'll look at pulling out Gradle. >>>>>>>>> >>>>>>>>> - Mark >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> - Mark >>>>>>>> >>>>>>>> http://about.me/markrmiller >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> - Mark >>>>>>> >>>>>>> http://about.me/markrmiller >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> http://www.needhamsoftware.com (work) >>>>>> http://www.the111shift.com (play) >>>>>> >>>>> >>>>> >>>>> -- >>>>> - Mark >>>>> >>>>> http://about.me/markrmiller >>>>> >>>> >>>> >>>> -- >>>> - Mark >>>> >>>> http://about.me/markrmiller >>>> >>> -- >>> - Mark >>> >>> http://about.me/markrmiller >>> >> >> >> -- >> - Mark >> >> http://about.me/markrmiller >> > > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) > -- - Mark http://about.me/markrmiller
