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)
