Re: gradle build gives spurious warnings about unferenced license files?
> > Only tangentially related, I wanna do a gradle bump (from 8.8 to 8.10), to > get better support for JDK 23, but ran into a couple of issues with how we > define properties - might be that we need a little tweaking in how we do > this. Maybe a gradle bump could fix the warnings, I dunno. > Hi Chris. I'll take care of this upgrade tonight. Dawid
Re: gradle build gives spurious warnings about unferenced license files?
Problem already solved! It was caused by this commit: https://github.com/apache/lucene/pull/12150 The problem is that the tasks for license checks have side-effects on global properties, so they have to run. The above optimization added a new output to one of the tasks, so it wan'st consistently executed. Fix is here: https://github.com/apache/lucene/pull/13696 Uwe Am 28.08.2024 um 18:27 schrieb Chris Hegarty: On 28 Aug 2024, at 15:46, Michael McCandless wrote: I opened https://github.com/apache/lucene/issues/13695 to try to get to the bottom of this. Thanks for opening this issue Mike. I’ve seen the warnings too, but have no idea why they happen. Only tangentially related, I wanna do a gradle bump (from 8.8 to 8.10), to get better support for JDK 23, but ran into a couple of issues with how we define properties - might be that we need a little tweaking in how we do this. Maybe a gradle bump could fix the warnings, I dunno. -Chris. Mike McCandless http://blog.mikemccandless.com On Tue, Aug 27, 2024 at 4:29 PM Michael McCandless wrote: Hi Team, When I run "gradle check" on main, sometimes I get seemingly false positive warnings about dozens of unferenced license files, like this: WARNING: there were unreferenced files under license folder: - /s1/l/trunk/lucene/licenses/antlr4-runtime-LICENSE-BSD.txt - /s1/l/trunk/lucene/licenses/antlr4-runtime-NOTICE.txt - /s1/l/trunk/lucene/licenses/asm-LICENSE-BSD_LIKE.txt - /s1/l/trunk/lucene/licenses/asm-NOTICE.txt - /s1/l/trunk/lucene/licenses/asm-commons-LICENSE-BSD_LIKE.txt - /s1/l/trunk/lucene/licenses/asm-commons-NOTICE.txt - /s1/l/trunk/lucene/licenses/assertj-core-LICENSE-ASL.txt - /s1/l/trunk/lucene/licenses/assertj-core-NOTICE.txt - /s1/l/trunk/lucene/licenses/commons-codec-LICENSE-ASL.txt - /s1/l/trunk/lucene/licenses/commons-codec-NOTICE.txt ... If I then do a "./gradlew clean" and again "./gradlew check" the warnings seem to go away, but then if I immediately run "./gradlew check" again (after clean then check), the warnings return. Does anyone know why this happens? Can we stop the false positives? God forbid I someday actually introduce a true positive warning, I would never notice :) Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: gradle build gives spurious warnings about unferenced license files?
> On 28 Aug 2024, at 15:46, Michael McCandless > wrote: > > I opened https://github.com/apache/lucene/issues/13695 to try to get to the > bottom of this. Thanks for opening this issue Mike. I’ve seen the warnings too, but have no idea why they happen. Only tangentially related, I wanna do a gradle bump (from 8.8 to 8.10), to get better support for JDK 23, but ran into a couple of issues with how we define properties - might be that we need a little tweaking in how we do this. Maybe a gradle bump could fix the warnings, I dunno. -Chris. > Mike McCandless > > http://blog.mikemccandless.com > > > On Tue, Aug 27, 2024 at 4:29 PM Michael McCandless > wrote: > Hi Team, > > When I run "gradle check" on main, sometimes I get seemingly false positive > warnings about dozens of unferenced license files, like this: > > WARNING: there were unreferenced files under license folder: > - /s1/l/trunk/lucene/licenses/antlr4-runtime-LICENSE-BSD.txt > - /s1/l/trunk/lucene/licenses/antlr4-runtime-NOTICE.txt > - /s1/l/trunk/lucene/licenses/asm-LICENSE-BSD_LIKE.txt > - /s1/l/trunk/lucene/licenses/asm-NOTICE.txt > - /s1/l/trunk/lucene/licenses/asm-commons-LICENSE-BSD_LIKE.txt > - /s1/l/trunk/lucene/licenses/asm-commons-NOTICE.txt > - /s1/l/trunk/lucene/licenses/assertj-core-LICENSE-ASL.txt > - /s1/l/trunk/lucene/licenses/assertj-core-NOTICE.txt > - /s1/l/trunk/lucene/licenses/commons-codec-LICENSE-ASL.txt > - /s1/l/trunk/lucene/licenses/commons-codec-NOTICE.txt > ... > > If I then do a "./gradlew clean" and again "./gradlew check" the warnings > seem to go away, but then if I immediately run "./gradlew check" again (after > clean then check), the warnings return. > > Does anyone know why this happens? Can we stop the false positives? God > forbid I someday actually introduce a true positive warning, I would never > notice :) > > Mike McCandless > > http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: gradle build gives spurious warnings about unferenced license files?
I opened https://github.com/apache/lucene/issues/13695 to try to get to the bottom of this. Mike McCandless http://blog.mikemccandless.com On Tue, Aug 27, 2024 at 4:29 PM Michael McCandless < luc...@mikemccandless.com> wrote: > Hi Team, > > When I run "gradle check" on main, sometimes I get seemingly false > positive warnings about dozens of unferenced license files, like this: > > WARNING: there were unreferenced files under license folder: > - /s1/l/trunk/lucene/licenses/antlr4-runtime-LICENSE-BSD.txt > - /s1/l/trunk/lucene/licenses/antlr4-runtime-NOTICE.txt > - /s1/l/trunk/lucene/licenses/asm-LICENSE-BSD_LIKE.txt > - /s1/l/trunk/lucene/licenses/asm-NOTICE.txt > - /s1/l/trunk/lucene/licenses/asm-commons-LICENSE-BSD_LIKE.txt > - /s1/l/trunk/lucene/licenses/asm-commons-NOTICE.txt > - /s1/l/trunk/lucene/licenses/assertj-core-LICENSE-ASL.txt > - /s1/l/trunk/lucene/licenses/assertj-core-NOTICE.txt > - /s1/l/trunk/lucene/licenses/commons-codec-LICENSE-ASL.txt > - /s1/l/trunk/lucene/licenses/commons-codec-NOTICE.txt > ... > > If I then do a "./gradlew clean" and again "./gradlew check" the warnings > seem to go away, but then if I immediately run "./gradlew check" again > (after clean then check), the warnings return. > > Does anyone know why this happens? Can we stop the false positives? God > forbid I someday actually introduce a true positive warning, I would never > notice :) > > Mike McCandless > > http://blog.mikemccandless.com >
Re: Gradle build optimization
> Huh, I thought by "cd lucene/core" would be equivalent to "-p lucene/core" > from the root checkout? I don't think it is. It's a wrapper script - I'm not sure it recognizes where it's run from. > real0m4.802s > user0m2.988s > sys 0m0.189s > > Not much better? Ok. In that case, it's something else. I have a strong suspicion that gradle's test task scans through all the classes or does something weird. You could try running with a build scan so that there are more details on which phase actually takes those 5 seconds. D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build optimization
[Adding Jerome back on CC -- not sure he's sub'd] More below: On Wed, Oct 20, 2021 at 10:37 AM Dawid Weiss wrote: > > I do! I am now using pure Gradle/Lucene clean checkout defaults, from > quite a while back (last time you scolded me ;) ) > > Oh, I never scold. I politely pass over the torch of wisdom (or > bullwaste, depending on the day). :) > Perfect! I love it :) > > But it's still slower than ant on 8.x was/is, plus it makes me pay a > warmup penalty the first time (at defaults anyways). > > Part of the startup penalty is the evaluation of various scripts and > settings that never get used. There are gradle-sque ways of avoiding > that (lazy evaluation) but they do increase code complexity (in my > opinion). The first-time compilation should be improved by moving > scripts into buildSrc (or plugins). Again: this removes the clarity of > individual aspect-based scripts (again: my opinion). > OK > > so then I tested on main, with JDK15, also in cwd lucene/core: "time > ../../gradlew test --tests > "org.apache.lucene.index.TestIndexWriter.testGetCommitData" > -Ptests.seed=D708CEE0862DB94C > ignored": > > You're running the test task in *each and every submodule* that > declares it, then filter for a specific test case. Try this: > Huh, I thought by "cd lucene/core" would be equivalent to "-p lucene/core" from the root checkout? time ../../gradlew -p lucene/core test --tests > "org.apache.lucene.index.TestIndexWriter.testGetCommitData" > -Ptests.seed=D708CEE0862DB94C > ignored > I tried that but the "lucene/core" seems to incorrectly "stack up": beast3:core[main]$ time ../../gradlew test -p lucene/core --tests "org.apache.lucene.index.TestIndexWriter.testGetCommitData" -Ptests.seed=D708CEE0862DB94C Starting a Gradle Daemon (subsequent builds will be faster) FAILURE: Build failed with an exception. * What went wrong: The specified project directory '/l/trunk/lucene/core/lucene/core' does not exist. I think you either "cd lucene/core" or you stay in ROOT and pass -p lucene:core:test (or -p lucene/core?)? > or full scoped task :lucene:core:test. Should be slightly better. > OK I tried that, in ROOT of the checkout "time ./gradlew lucene:core:test --tests "org.apache.lucene.index.TestIndexWriter.testGetCommitData" -Ptests.seed=D708CEE0862DB94C > ignore" (discard first warmup, then:) real0m4.514s user0m3.090s sys 0m0.186s real0m4.587s user0m3.029s sys 0m0.186s real0m4.802s user0m2.988s sys 0m0.189s Not much better? > Also, I'm running on a 128 core crazy beast of a box (Ryzen Threadripper > 3990X), 256 GB RAM, fast SSD, 10g networking, etc. :) > I'm jealous. > LOL well there are even faster CPUs now I think, so I'm jealous of them! Turtles all the way down ... > > Also I want to thank you for migrating us to Gradle in the first place > > No need to thank anybody. It's fun. > Awesome! > > But I really don't like waiting :) And yes maybe I just should learn > how to use fancy IDE debuggers instead of SOP + rerun many times ;) > > IntelliJ works very well for me with Lucene (especially if gradle is > not used for compilation/ test launching). You may also look at this - > never tried it but it looks like something your all-green terminals > may look forward to: > > > https://docs.gradle.org/current/userguide/command_line_interface.html#sec:continuous_build Whoa, that does look interesting! Thanks for the pointer. Mike
Re: Gradle build optimization
I'm glad to see that this initiative creates a lot of excitement! I however need to narrow down a bit the scope of expectations as my plan is not to go too deep into the project's logic (won't cover tests taking too long to run for instance) but rather applying some techniques to avoid task execution when not needed. This will happen without involving extra complexity hopefully. We'll probably discuss that with the PR. So far, here is the Jira ticket, feel free to drop your comments in there as well: https://issues.apache.org/jira/browse/LUCENE-10195 Best, Jerome On Wed, Oct 20, 2021 at 4:42 PM Dawid Weiss wrote: > > The fully scoped one doesn't enjoy tab completion in the shell though. > > So I always do path-based "-p lucene/core" because it is less typing > > and less mistakes. > > Funny, it's exactly why I prefer -p as well. > > D. >
Re: Gradle build optimization
> The fully scoped one doesn't enjoy tab completion in the shell though. > So I always do path-based "-p lucene/core" because it is less typing > and less mistakes. Funny, it's exactly why I prefer -p as well. D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build optimization
On Wed, Oct 20, 2021 at 10:37 AM Dawid Weiss wrote: > You're running the test task in *each and every submodule* that > declares it, then filter for a specific test case. Try this: > > time ../../gradlew -p lucene/core test --tests > "org.apache.lucene.index.TestIndexWriter.testGetCommitData" > -Ptests.seed=D708CEE0862DB94C > ignored > > or full scoped task :lucene:core:test. Should be slightly better. > The fully scoped one doesn't enjoy tab completion in the shell though. So I always do path-based "-p lucene/core" because it is less typing and less mistakes. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build optimization
> I do! I am now using pure Gradle/Lucene clean checkout defaults, from quite > a while back (last time you scolded me ;) ) Oh, I never scold. I politely pass over the torch of wisdom (or bullwaste, depending on the day). :) > But it's still slower than ant on 8.x was/is, plus it makes me pay a warmup > penalty the first time (at defaults anyways). Part of the startup penalty is the evaluation of various scripts and settings that never get used. There are gradle-sque ways of avoiding that (lazy evaluation) but they do increase code complexity (in my opinion). The first-time compilation should be improved by moving scripts into buildSrc (or plugins). Again: this removes the clarity of individual aspect-based scripts (again: my opinion). > so then I tested on main, with JDK15, also in cwd lucene/core: "time > ../../gradlew test --tests > "org.apache.lucene.index.TestIndexWriter.testGetCommitData" > -Ptests.seed=D708CEE0862DB94C > ignored": You're running the test task in *each and every submodule* that declares it, then filter for a specific test case. Try this: time ../../gradlew -p lucene/core test --tests "org.apache.lucene.index.TestIndexWriter.testGetCommitData" -Ptests.seed=D708CEE0862DB94C > ignored or full scoped task :lucene:core:test. Should be slightly better. > Also, I'm running on a 128 core crazy beast of a box (Ryzen Threadripper > 3990X), 256 GB RAM, fast SSD, 10g networking, etc. :) I'm jealous. > Also I want to thank you for migrating us to Gradle in the first place No need to thank anybody. It's fun. > But I really don't like waiting :) And yes maybe I just should learn how to > use fancy IDE debuggers instead of SOP + rerun many times ;) IntelliJ works very well for me with Lucene (especially if gradle is not used for compilation/ test launching). You may also look at this - never tried it but it looks like something your all-green terminals may look forward to: https://docs.gradle.org/current/userguide/command_line_interface.html#sec:continuous_build Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build optimization
It is very possible I am holding gradlew wrong, like this: https://i2.wp.com/www.adatosystems.com/wp-content/uploads/2019/03/wrong_tool.jpg Mike McCandless http://blog.mikemccandless.com On Wed, Oct 20, 2021 at 10:21 AM Michael McCandless < luc...@mikemccandless.com> wrote: > Jerome, if you are not sub'd to the Lucene dev list, then you maybe missed > some of the replies here. I'm CC'ing you back on here. > > More responses below: > > On Wed, Oct 20, 2021 at 8:45 AM Dawid Weiss wrote: > >> >> >>> I was just annoyed yesterday at how long running a single test case >>> takes. >>> >> >> Use the background daemon, Mike. >> > > I do! I am now using pure Gradle/Lucene clean checkout defaults, from > quite a while back (last time you scolded me ;) ) > > And the defaults enable the daemon I think? Yeah, just confirmed. > > But it's still slower than ant on 8.x was/is, plus it makes me pay a > warmup penalty the first time (at defaults anyways). I just tested 8.x in > cwd lucene/core and JDK8: "time ant test -Dtestcase=TestIndexWriter > -Dtestmethod=testGetCommitData > ignored" three times: > > real0m2.609s > > user0m10.583s > > sys 0m0.590s > > > real0m2.585s > > user0m10.329s > > sys 0m0.827s > > > real0m2.610s > > user0m10.458s > > sys 0m0.606s > > > > so then I tested on main, with JDK15, also in cwd lucene/core: "time > ../../gradlew test --tests > "org.apache.lucene.index.TestIndexWriter.testGetCommitData" > -Ptests.seed=D708CEE0862DB94C > ignored": > > ** (first time discarded due to "daemon" warmup its fire up) > > real0m4.447s > > user0m2.956s > > sys 0m0.217s > > > real0m4.399s > > user0m3.028s > > sys 0m0.233s > > > real0m4.404s > > user0m3.021s > > sys 0m0.181s > > > Now I know there are many differences besides ant/gradle! Maybe JDK15's > startup time got worse. The random seed does not carry over. Lucene's > sources are different, etc. And maybe I should care about a second or two > :) But I do! > > Also, I'm running on a 128 core crazy beast of a box (Ryzen Threadripper > 3990X), 256 GB RAM, fast SSD, 10g networking, etc. :) > > Also I want to thank you for migrating us to Gradle in the first place -- > I know that was a crazy amount of work! I'm trying not to complain (too > much). But I really don't like waiting :) And yes maybe I just should > learn how to use fancy IDE debuggers instead of SOP + rerun many times ;) > > Mike McCandless > > http://blog.mikemccandless.com >
Re: Gradle build optimization
Jerome, if you are not sub'd to the Lucene dev list, then you maybe missed some of the replies here. I'm CC'ing you back on here. More responses below: On Wed, Oct 20, 2021 at 8:45 AM Dawid Weiss wrote: > > >> I was just annoyed yesterday at how long running a single test case takes. >> > > Use the background daemon, Mike. > I do! I am now using pure Gradle/Lucene clean checkout defaults, from quite a while back (last time you scolded me ;) ) And the defaults enable the daemon I think? Yeah, just confirmed. But it's still slower than ant on 8.x was/is, plus it makes me pay a warmup penalty the first time (at defaults anyways). I just tested 8.x in cwd lucene/core and JDK8: "time ant test -Dtestcase=TestIndexWriter -Dtestmethod=testGetCommitData > ignored" three times: real0m2.609s user0m10.583s sys 0m0.590s real0m2.585s user0m10.329s sys 0m0.827s real0m2.610s user0m10.458s sys 0m0.606s so then I tested on main, with JDK15, also in cwd lucene/core: "time ../../gradlew test --tests "org.apache.lucene.index.TestIndexWriter.testGetCommitData" -Ptests.seed=D708CEE0862DB94C > ignored": ** (first time discarded due to "daemon" warmup its fire up) real0m4.447s user0m2.956s sys 0m0.217s real0m4.399s user0m3.028s sys 0m0.233s real0m4.404s user0m3.021s sys 0m0.181s Now I know there are many differences besides ant/gradle! Maybe JDK15's startup time got worse. The random seed does not carry over. Lucene's sources are different, etc. And maybe I should care about a second or two :) But I do! Also, I'm running on a 128 core crazy beast of a box (Ryzen Threadripper 3990X), 256 GB RAM, fast SSD, 10g networking, etc. :) Also I want to thank you for migrating us to Gradle in the first place -- I know that was a crazy amount of work! I'm trying not to complain (too much). But I really don't like waiting :) And yes maybe I just should learn how to use fancy IDE debuggers instead of SOP + rerun many times ;) Mike McCandless http://blog.mikemccandless.com
Re: Gradle build optimization
Btw. this is a placeholder for some of the known bits that require solving. https://issues.apache.org/jira/browse/LUCENE-9871 It'd be awesome to see some help from you guys at Gradle to solve the non-trivial things: - test runner and early/ internal JVM output (the issue I mentioned before), - test runner test case ordering optimization (load balancing between worker JVMs); currently the long-tail test case can slow down builds significantly. - support for user-local gradle.properties or computed properties there (we currently generate this file because it'll be slightly different for every developer, this requires a non-optimal first run), - support for project-controlled up-to-date mechanism (versioned artifact checksums) that is not bypassed on the first run. This is needed for generated resources - I didn't figure out how to do it other than with ugly hacks. If any of these is of interest to you, I can provide more pointers, of course. Let me know! Dawid On Wed, Oct 20, 2021 at 1:48 PM Jerome Prinet wrote: > Hi Lucene team! > I am a software engineer at Gradle and I'd like to help you optimize > Lucene's Gradle build. > I have already been working on this topic and I'd like to open a PR. > Should I start by creating a JIRA issue first? > Please let me know how to proceed. > Kind regards, > > -- > > Jerome Prinet > Senior Software Engineer > Gradle > W. gradle.com > >
Re: Gradle build optimization
On Wed, Oct 20, 2021 at 8:52 AM Dawid Weiss wrote: > > Can you tell us a bit more about which directions these mentioned > optimizations apply to? If it's about build caches then it's already > been discussed as a contribution to Solr: Sure, something like that is definitely worthy of discussion first. I don't understand why build caches are ever needed. If the outputs are up-to-date with the inputs, then it should say UP-TO-DATE. If I ask for "clean", then I really mean it, and expect the next run to be slower. These are simple rules for any build system (Makefile, etc). Gradle is no exception. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build optimization
Also, run an explicit project task (or narrow down the project with -p); if you're running a generic 'test' over all projects it may have to run/ scan all the classes. If you provide a full command line you used it'll be easier why it takes so long. D. On Wed, Oct 20, 2021 at 2:44 PM Dawid Weiss wrote: > > >> >> I was just annoyed yesterday at how long running a single test case takes. > > > Use the background daemon, Mike. > > D. > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build optimization
Can you tell us a bit more about which directions these mentioned optimizations apply to? If it's about build caches then it's already been discussed as a contribution to Solr: https://issues.apache.org/jira/browse/SOLR-15603 Also, it'd be great to see some feedback for more fundamental issues within gradle -- like this one: https://issues.apache.org/jira/browse/LUCENE-9120 https://github.com/gradle/gradle/issues/11609 (this is marked as closed -- incorrectly; it's still a bug and always has been). Dawid On Wed, Oct 20, 2021 at 1:48 PM Jerome Prinet wrote: > > Hi Lucene team! > I am a software engineer at Gradle and I'd like to help you optimize Lucene's > Gradle build. > I have already been working on this topic and I'd like to open a PR. > Should I start by creating a JIRA issue first? > Please let me know how to proceed. > Kind regards, > > -- > > Jerome Prinet > Senior Software Engineer > Gradle > W. gradle.com > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build optimization
> I was just annoyed yesterday at how long running a single test case takes. > Use the background daemon, Mike. D.
Re: Gradle build optimization
Whoa, hi Jerome, yes please :) I was just annoyed yesterday at how long running a single test case takes. Please create an issue and reference it (in all caps, i.e. LUCENE-X) in the description. Thanks, Mike McCandless http://blog.mikemccandless.com On Wed, Oct 20, 2021 at 7:48 AM Jerome Prinet wrote: > Hi Lucene team! > I am a software engineer at Gradle and I'd like to help you optimize > Lucene's Gradle build. > I have already been working on this topic and I'd like to open a PR. > Should I start by creating a JIRA issue first? > Please let me know how to proceed. > Kind regards, > > -- > > Jerome Prinet > Senior Software Engineer > Gradle > W. gradle.com > >
Re: Gradle build, where's the output?
SOLR-14888 I’m a bit underwater now, so probably won’t get to a PR for a while. > On Sep 22, 2020, at 12:33 PM, Mike Drob wrote: > > It likely disappeared when I switched us to use the distribution plugin. Feel > free to open either a JIRA or PR for it, depending on your comfort. > > On Tue, Sep 22, 2020 at 11:11 AM Erick Erickson > wrote: > We’re probably talking about different things. I have access to all the > folders, I think our gradle build has changed recently and we stopped > printing out a message for where the results of a specific task wound up. > > > > Always possible it’s something else of course, I’m checking whether it’s a > change to our build scripts which have been changing a lot lately. > > > > > On Sep 22, 2020, at 11:51 AM, Martin Gainty wrote: > > > > > > travis doc suggests user account does not have 'read access' to dependency > > folder > > > > > > https://docs.travis-ci.com/user/languages/java/#projects-using-gradle > > > > > > m- > > > > > > From: Erick Erickson > > > Sent: Tuesday, September 22, 2020 10:48 AM > > > To: dev@lucene.apache.org > > > Subject: Gradle build, where's the output? > > > > > > The Gradle build used to print out where to find the artifacts for the > > “assemble” and “dev” tasks, but that disappeared sometime. Is this > > intentional? It really helped me the first time I tried to run Solr after > > building with Gradle… > > > > > > Currently, “gradlew tasks” does print the location of the artifacts for the > > “dev” target, but not the “assemble” target, that might suffice. > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build, where's the output?
It likely disappeared when I switched us to use the distribution plugin. Feel free to open either a JIRA or PR for it, depending on your comfort. On Tue, Sep 22, 2020 at 11:11 AM Erick Erickson wrote: > We’re probably talking about different things. I have access to all the > folders, I think our gradle build has changed recently and we stopped > printing out a message for where the results of a specific task wound up. > > > > Always possible it’s something else of course, I’m checking whether it’s a > change to our build scripts which have been changing a lot lately. > > > > > On Sep 22, 2020, at 11:51 AM, Martin Gainty wrote: > > > > > > travis doc suggests user account does not have 'read access' to > dependency folder > > > > > > https://docs.travis-ci.com/user/languages/java/#projects-using-gradle > > > > > > m- > > > > > > From: Erick Erickson > > > Sent: Tuesday, September 22, 2020 10:48 AM > > > To: dev@lucene.apache.org > > > Subject: Gradle build, where's the output? > > > > > > The Gradle build used to print out where to find the artifacts for the > “assemble” and “dev” tasks, but that disappeared sometime. Is this > intentional? It really helped me the first time I tried to run Solr after > building with Gradle… > > > > > > Currently, “gradlew tasks” does print the location of the artifacts for > the “dev” target, but not the “assemble” target, that might suffice. > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > >
Re: Gradle build, where's the output?
We’re probably talking about different things. I have access to all the folders, I think our gradle build has changed recently and we stopped printing out a message for where the results of a specific task wound up. Always possible it’s something else of course, I’m checking whether it’s a change to our build scripts which have been changing a lot lately. > On Sep 22, 2020, at 11:51 AM, Martin Gainty wrote: > > travis doc suggests user account does not have 'read access' to dependency > folder > > https://docs.travis-ci.com/user/languages/java/#projects-using-gradle > > m- > > From: Erick Erickson > Sent: Tuesday, September 22, 2020 10:48 AM > To: dev@lucene.apache.org > Subject: Gradle build, where's the output? > > The Gradle build used to print out where to find the artifacts for the > “assemble” and “dev” tasks, but that disappeared sometime. Is this > intentional? It really helped me the first time I tried to run Solr after > building with Gradle… > > Currently, “gradlew tasks” does print the location of the artifacts for the > “dev” target, but not the “assemble” target, that might suffice. > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build, where's the output?
travis doc suggests user account does not have 'read access' to dependency folder https://docs.travis-ci.com/user/languages/java/#projects-using-gradle m- From: Erick Erickson Sent: Tuesday, September 22, 2020 10:48 AM To: dev@lucene.apache.org Subject: Gradle build, where's the output? The Gradle build used to print out where to find the artifacts for the “assemble” and “dev” tasks, but that disappeared sometime. Is this intentional? It really helped me the first time I tried to run Solr after building with Gradle… Currently, “gradlew tasks” does print the location of the artifacts for the “dev” target, but not the “assemble” target, that might suffice. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build question
> WDYT about making 3g the default (I volunteer)? I honestly don't know what consumes so much memory in the daemon - whether it's the caches or something else. It doesn't seem the build should need SO much memory... Feel free to bump but it'd be even better to figure out why it needs so much and perhaps clean it up! :) D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build is on master
Hi Uwe, > Can we correct it on ant's side somehow (by ignoring jetty-start-*)? I've just committed a quick workaround so that ant-regenerate doesn't wipe this particular file (on master) so that builds can pass. I don't know any better solution to this. If we're looking to switching to gradle then I'd rather consider the gradle build the primary source of truth and fix ant to what's required for it to pass. Let me know what you think though. D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build is on master
> Thanks Dawid – great work! Thank you all. I don't think it's particularly great, but definitely a step forward from ant which has gotten very complex and where simple things are difficult to achieve. Gradle is not without its own issues (some known, some waiting to be discovered) but it is manageable I think. > there is a small problem with Jenkins (still running ANT build; I may add a > second one running the gradle build!): Gradle on a CI will require some overrides -- I'd disable the daemon and set the number of workers manually. Something like: ./gradlew --no-daemon --max-workers=5 ... In the initial stage it'd be enough if you just ran precommit and other checks, without tests: ./gradlew --no-daemon --max-workers=5 precommit check -x test This would be helpful enough! Of course you can run tests as well but they take approximately the same amount of time as with ant in my experience. > The Jenkins build does a license and JAR file check by first deleting all > checksum files and then regenerate all of them from the downloaded artifacts. > Afterwards it checks that the GIT checkout is clean. This is done to detect > obsolete or incorrect checksum files. This only works for sha files, right? Because I removed quite a few other dangling files when I implemented this for the gradle counterpart (Gradle build does this kind of check as part of precommit). > With the gradle update you added the shaded jetty JAR file, but the old ANT > build seems to still use the old/different name. It means after checksum > regeneration the checkout is no longer clean: Correct. The shaded jetty jar file is the only exception I made. It just didn't fit the logical way those files are looked up (by their real artifact name). In fact I ignore "start.jar" in gradle, otherwise it'd be reported as a dangling file... > /home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:494: Source > checkout is dirty (unversioned/missing files) after running tests!!! > Offending files: > > * solr/licenses/jetty-start-9.4.24.v20191120-shaded.jar.sha1 Can we correct it on ant's side somehow (by ignoring jetty-start-*)? This file points at a real dependency and you can tell what this dependency is while "start.jar.sha1" doesn't really mean anything (and it isn't easy to figure out which license applies to it, etc.). There are more oddball checksums in there that don't really match true redistributed project dependencies [1] but this one is the most annoying one I think. D. [1] https://github.com/apache/lucene-solr/blob/master/gradle/validation/jar-checks.gradle#L340-L368 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Gradle build is on master
Thanks Dawid – great work! there is a small problem with Jenkins (still running ANT build; I may add a second one running the gradle build!): The Jenkins build does a license and JAR file check by first deleting all checksum files and then regenerate all of them from the downloaded artifacts. Afterwards it checks that the GIT checkout is clean. This is done to detect obsolete or incorrect checksum files. With the gradle update you added the shaded jetty JAR file, but the old ANT build seems to still use the old/different name. It means after checksum regeneration the checkout is no longer clean: /home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:494: Source checkout is dirty (unversioned/missing files) after running tests!!! Offending files: * solr/licenses/jetty-start-9.4.24.v20191120-shaded.jar.sha1 It does not seem to happen on 8.x branch so it look like caused by Gradle build. See here: <https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/25336/console> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/25336/console Uwe - Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de From: David Smiley Sent: Wednesday, January 15, 2020 11:24 PM To: Solr/Lucene Dev Subject: Re: Gradle build is on master This is a big milestone indeed! Thanks Mark, Dawid, Erick, Dat, Mike, etc. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Jan 15, 2020 at 2:00 PM Anshum Gupta mailto:ans...@anshumgupta.net> > wrote: Thank you Dawid and everyone else ! On Wed, Jan 15, 2020 at 5:33 AM Dawid Weiss mailto:dawid.we...@gmail.com> > wrote: Hello, I've just merged the gradle-master branch so gradle build can be used on master. As previously mentioned, it isn't a complete replacement for ant but I think we're getting darn close and common tasks are fairly well covered. Any issues or concerns: create an issue in jira or send an e-mail to the mailing list, CCing me directly. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org <mailto:dev-unsubscr...@lucene.apache.org> For additional commands, e-mail: dev-h...@lucene.apache.org <mailto:dev-h...@lucene.apache.org> -- Anshum Gupta
Re: Gradle build is on master
This is a big milestone indeed! Thanks Mark, Dawid, Erick, Dat, Mike, etc. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Jan 15, 2020 at 2:00 PM Anshum Gupta wrote: > Thank you Dawid and everyone else ! > > On Wed, Jan 15, 2020 at 5:33 AM Dawid Weiss wrote: > >> Hello, >> >> I've just merged the gradle-master branch so gradle build can be used >> on master. >> >> As previously mentioned, it isn't a complete replacement for ant but I >> think we're getting darn close and common tasks are fairly well >> covered. >> >> Any issues or concerns: create an issue in jira or send an e-mail to >> the mailing list, CCing me directly. >> >> Dawid >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > > -- > Anshum Gupta >
Re: Gradle build is on master
Thank you Dawid and everyone else ! On Wed, Jan 15, 2020 at 5:33 AM Dawid Weiss wrote: > Hello, > > I've just merged the gradle-master branch so gradle build can be used > on master. > > As previously mentioned, it isn't a complete replacement for ant but I > think we're getting darn close and common tasks are fairly well > covered. > > Any issues or concerns: create an issue in jira or send an e-mail to > the mailing list, CCing me directly. > > Dawid > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Anshum Gupta
Re: Gradle build is on master
Thanks Dawid. Big milestone reached. Thanks Mark, Erick and everyone else who helped. I'm super excited. On Wed, 15 Jan, 2020, 7:03 PM Dawid Weiss, wrote: > Hello, > > I've just merged the gradle-master branch so gradle build can be used > on master. > > As previously mentioned, it isn't a complete replacement for ant but I > think we're getting darn close and common tasks are fairly well > covered. > > Any issues or concerns: create an issue in jira or send an e-mail to > the mailing list, CCing me directly. > > Dawid > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Gradle build to land on master
> Are you thinking to have a gradle task that fails if there is mismatch > between ant and gradle dependencies versions? When you run './gradlew licenses' it currently applies all the checks against the same "licenses" folders as ant. So when you change something in ant and not do a corresponding change to gradle dependencies, "gradlew precommit" (or "licenses") will fail the build. Technically there are a few ignored entries inside the gradle validation script (to skip things like "start.jar"); everything else is resolved directly from declared dependencies. https://github.com/apache/lucene-solr/blob/gradle-master/gradle/validation/jar-checks.gradle#L340-L368 The gradle validation script is more strict than the ant build -- it fails if there are leftover files that don't belong anywhere, for example. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build to land on master
+1 The sooner the better > This would ensure consistency in dependencies, for example Are you thinking to have a gradle task that fails if there is mismatch between ant and gradle dependencies versions? Jan > 8. jan. 2020 kl. 15:29 skrev Dawid Weiss : > > I think the gradle-master branch is already workable enough to land on master. > > If you're not familiar with gradle then, once merged, run "gradlew help". > > Some notes. > > 1) I have been running tests on Windows and Linux, they're ok. The > output is slightly different from ANT's but I think it's fine for > working. > > 2) The speed of compilation and running tests selectively is much > better than ant's, especially on multicore machines. > > 3) I use IntelliJ idea and the project imports into the IDE without > any special handling. Code formatting and such may need to be adjusted > though. > > 4) Some things are incomplete (precommit does a subset of checks). > Some are missing (regeneration tasks). Some are different (handling of > dependencies, build output folder locations). It will take some time > and learning to live with a new build system. I tried to provide short > guides into selective areas (they're available as help tasks or plain > text files under help/). > > 5) If something does *not* work, let me know. > > 6) It'd be nice if we had a build job somewhere on a faster machine > that would run at least "gradlew precommit check -x test" so that > rudimentary checks are applied, without running all the tests. This > would ensure consistency in dependencies, for example. > > 7) The parallel branch (gradle-master) and issue (LUCENE-9077) will be > kept open and occasionally merged back and forth. > > I have to shift more focus to my daily job but will help out and chip > at the remaining bits, time permitting. > > Dawid > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build to land on master
> Maybe the README should be altered a little bit to encourage people to mess > around with the gradle build. Currently all the instructions in the root > README are ant-based. Will do it, thanks for the suggestion. D - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build to land on master
Dawid, I think the plan is good, and thanks for working on it. Maybe the README should be altered a little bit to encourage people to mess around with the gradle build. Currently all the instructions in the root README are ant-based. I am thinking just a simple one-liner that explains it: gradle is WIP, patches welcome, whatever you want it to say. On Wed, Jan 8, 2020 at 12:44 PM Dawid Weiss wrote: > > So are we going to be able to do things like EA testing? > > We should be able to, eventually. For now I explicitly limited the > environment to a particular Java/ Gradle version so that > we're all on the same page... Gradle is a much more complicated (and > fragile) ecosystem than ant. Weird things (like the one you > experienced, argh!) can happen out of nowhere. > > Perhaps I should also clarify: the ant build will still work (on > master) until we can iron out all the problems. I just don't want to > keep the branch separate anymore. One of the reasons for this is > simple: I've had more feedback in the last 5 minutes than I had in the > last three weeks. :) I am also afraid the whole effort will die if > there is only one person effectively using it -- this is what happened > with Mark's branch. I tried to bring it to a functional level and I > think it's there -- I've been working with it for over a month now. > > Dawid > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Gradle build to land on master
> So are we going to be able to do things like EA testing? We should be able to, eventually. For now I explicitly limited the environment to a particular Java/ Gradle version so that we're all on the same page... Gradle is a much more complicated (and fragile) ecosystem than ant. Weird things (like the one you experienced, argh!) can happen out of nowhere. Perhaps I should also clarify: the ant build will still work (on master) until we can iron out all the problems. I just don't want to keep the branch separate anymore. One of the reasons for this is simple: I've had more feedback in the last 5 minutes than I had in the last three weeks. :) I am also afraid the whole effort will die if there is only one person effectively using it -- this is what happened with Mark's branch. I tried to bring it to a functional level and I think it's there -- I've been working with it for over a month now. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build to land on master
It is crazy classfiles are involved here at all. It is even crazier to be reading classfiles of the JDK itself. I just asked to print the help... crazy groovy On Wed, Jan 8, 2020 at 12:27 PM Uwe Schindler wrote: > Hi, > > Sorry, this is a no-go for going to gradle. We currently want to build and > test Lucene with all newer Java versions, including EA releases. I have no > idea why the Gradle people are not looking into the issue of > forward-compatibility. > > I had a long discussion already on the OpenJDK mailing lists about the > classfile version issue. The problem is mainly ASM that's used for bytecode > analysis where Gradle and Groovy depend on. If you pass ASM a classfile > version that it does not unerstand it brings this error. > > I had a discussion with Remi Forax. My proposal would be: > ClassReader should have 2 modes: > - strict mode that enables all features (like you can add filtering on top > of like method renames, and so pass the ClassReader (as visitor) to a > ClassWriter. This strict mode ensures that a ClassReader then passed to > ClassWriter produces the same class file. The requires that ASM fully > understands the class file. > - lenient mode: This marks the classreader/visitor as "risky". When > passing this to ClassReader, it can open any class file, also those with > newer class file versions. The classfile format is made in a way > (attributes) that you can easily read over features you don't understand. > In that case you can use a ClassReader like this to read method signatures, > run forbiddenapi checks,... (what MOST code out there using ASM is doing!). > The special flag on the visitor interface is then there to protect people. > If you pass a "lenient" class reader to a ClassWriter, the ClassWriter > complains. So you cannot open a ClassReader in lenient way and pass it to > ClassWriter, because that would produce a classfile where maybe a > significant part of stuff is missing/incorrect. > > In short: If there would be a non-picky ASM version / ASM mode like > proposed before - that can just be used for "analysis" of class files, > Gradle would be forward compatible. But Remi is too academic and also does > not want this because he sees some "maintenance" trouble. But this is why I > said strict mode and lenient mode. In lenient mode you cannot complain if > your code behaves wrong when you open a class file that is newer than the > version of ASM supports. > > In forbiddenapis I use hack to provide this leniency: When opening class > files, I just patch the version number. Maybe gradle should do the same - > IF AND ONLY IF IT DOES NOT USE IT FOR WRITING DERIVATIVE CLASS FILES: > > Maybe we could try to confive Gradle, Groovy and maybe Remi to take one of > those routes. Otherwise we cannot use Gradle with CI builds. > > An alternative here is to go the Elasticsearch approach: Gradle and the > Build runs with Java 11 and the Tests are running optionally with a later > version - by pasisng a system property pointing to a TestRunner JDK. > > Uwe > > - > Uwe Schindler > Achterdiek 19, D-28357 Bremen > https://www.thetaphi.de > eMail: u...@thetaphi.de > > > -Original Message- > > From: Dawid Weiss > > Sent: Wednesday, January 8, 2020 6:06 PM > > To: Lucene Dev > > Subject: Re: Gradle build to land on master > > > > > right, that file is the exact one i change. the problem is if i change > it to 6.0.1, > > then it wants me to buy something. > > > > You can't change to any other gradle version -- stick to the version > > defined in the wrapper and java 11. It is a fragile environment - > > switching gradle version will cause plugin incompatibilities, etc. > > Sigh. > > > > We can't upgrade to gradle 6.x yet because palantir's plugin for > > dependency management doesn't work for me then. > > > > Different JVM configurations may be rough, especially with newer JVMs. > > > > D. > > > > > > > On Wed, Jan 8, 2020 at 10:08 AM Thomas Matthijs > wrote: > > >> > > >> ./gradlew should try to use gradle 5.6.4 see > > >> ./gradle/wrapper/gradle-wrapper.properties > > >> With java 11 this all builds fine for me (can export JAVA_HOME to > change) > > >> Which version of java are you using? the linked issue hints at java > 13? > > >> > > >> On Wed, 8 Jan 2020 at 16:01, Robert Muir wrote: > > >> > > > >> > Here is the issue: https://github.com/gradle/gradle/issues/8681 > > >> > > > >> > I tried upgrading gradle to 6.0.1,
Re: Gradle build to land on master
> Sorry, this is a no-go for going to gradle. We currently want to build and > test Lucene with all newer Java versions, including EA releases. I have no > idea why the Gradle people are not looking into the issue of > forward-compatibility. I'm sure there are ways to run tests against an arbitrary Java version: https://docs.gradle.org/6.0-rc-1/userguide/building_java_projects.html#sec:java_cross_compilation It's just not something I'm concerned with at the moment. Can't do everything at once. > An alternative here is to go the Elasticsearch approach: Gradle and the Build > runs with Java 11 and the Tests are running optionally with a later version - > by pasisng a system property pointing to a TestRunner JDK. Exactly. I'm sure there are ways to do it. D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Gradle build to land on master
Hi, Sorry, this is a no-go for going to gradle. We currently want to build and test Lucene with all newer Java versions, including EA releases. I have no idea why the Gradle people are not looking into the issue of forward-compatibility. I had a long discussion already on the OpenJDK mailing lists about the classfile version issue. The problem is mainly ASM that's used for bytecode analysis where Gradle and Groovy depend on. If you pass ASM a classfile version that it does not unerstand it brings this error. I had a discussion with Remi Forax. My proposal would be: ClassReader should have 2 modes: - strict mode that enables all features (like you can add filtering on top of like method renames, and so pass the ClassReader (as visitor) to a ClassWriter. This strict mode ensures that a ClassReader then passed to ClassWriter produces the same class file. The requires that ASM fully understands the class file. - lenient mode: This marks the classreader/visitor as "risky". When passing this to ClassReader, it can open any class file, also those with newer class file versions. The classfile format is made in a way (attributes) that you can easily read over features you don't understand. In that case you can use a ClassReader like this to read method signatures, run forbiddenapi checks,... (what MOST code out there using ASM is doing!). The special flag on the visitor interface is then there to protect people. If you pass a "lenient" class reader to a ClassWriter, the ClassWriter complains. So you cannot open a ClassReader in lenient way and pass it to ClassWriter, because that would produce a classfile where maybe a significant part of stuff is missing/incorrect. In short: If there would be a non-picky ASM version / ASM mode like proposed before - that can just be used for "analysis" of class files, Gradle would be forward compatible. But Remi is too academic and also does not want this because he sees some "maintenance" trouble. But this is why I said strict mode and lenient mode. In lenient mode you cannot complain if your code behaves wrong when you open a class file that is newer than the version of ASM supports. In forbiddenapis I use hack to provide this leniency: When opening class files, I just patch the version number. Maybe gradle should do the same - IF AND ONLY IF IT DOES NOT USE IT FOR WRITING DERIVATIVE CLASS FILES: Maybe we could try to confive Gradle, Groovy and maybe Remi to take one of those routes. Otherwise we cannot use Gradle with CI builds. An alternative here is to go the Elasticsearch approach: Gradle and the Build runs with Java 11 and the Tests are running optionally with a later version - by pasisng a system property pointing to a TestRunner JDK. Uwe - Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Dawid Weiss > Sent: Wednesday, January 8, 2020 6:06 PM > To: Lucene Dev > Subject: Re: Gradle build to land on master > > > right, that file is the exact one i change. the problem is if i change it > > to 6.0.1, > then it wants me to buy something. > > You can't change to any other gradle version -- stick to the version > defined in the wrapper and java 11. It is a fragile environment - > switching gradle version will cause plugin incompatibilities, etc. > Sigh. > > We can't upgrade to gradle 6.x yet because palantir's plugin for > dependency management doesn't work for me then. > > Different JVM configurations may be rough, especially with newer JVMs. > > D. > > > > On Wed, Jan 8, 2020 at 10:08 AM Thomas Matthijs wrote: > >> > >> ./gradlew should try to use gradle 5.6.4 see > >> ./gradle/wrapper/gradle-wrapper.properties > >> With java 11 this all builds fine for me (can export JAVA_HOME to change) > >> Which version of java are you using? the linked issue hints at java 13? > >> > >> On Wed, 8 Jan 2020 at 16:01, Robert Muir wrote: > >> > > >> > Here is the issue: https://github.com/gradle/gradle/issues/8681 > >> > > >> > I tried upgrading gradle to 6.0.1, but it seems now it wants me to buy > something? > >> > > >> > ]$ ./gradlew help > >> > Starting a Gradle Daemon (subsequent builds will be faster) > >> > > >> > FAILURE: Build failed with an exception. > >> > > >> > * Where: > >> > Build file '/Users/rob.muir/eclipse.workspace/lucene-solr/build.gradle' > >> > line: > 5 > >> > > >> > * What went wrong: > >> > An exception occurred applying plugin request [id: > >> > 'com.gradle.build-scan', > version: '
Re: Gradle build to land on master
So are we going to be able to do things like EA testing? On Wed, Jan 8, 2020 at 12:18 PM Dawid Weiss wrote: > > Can reproduce your problem with java 13, so guess only 11 is currently > supported > > For completeness: the build actually enforces gradle and Java version > and fails if there is a mismatch. The failure with Java 13 happens way > before this check has a chance to even run. > > > https://github.com/apache/lucene-solr/blob/gradle-master/gradle/validation/check-environment.gradle > > D. > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Gradle build to land on master
> Can reproduce your problem with java 13, so guess only 11 is currently > supported For completeness: the build actually enforces gradle and Java version and fails if there is a mismatch. The failure with Java 13 happens way before this check has a chance to even run. https://github.com/apache/lucene-solr/blob/gradle-master/gradle/validation/check-environment.gradle D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build to land on master
Can you file a pull request to remove it? I added it initially hoping
it'd help with test browsing but it's not going to work anyway
(because Solr emits half a gig of logs).
Dawid
On Wed, Jan 8, 2020 at 4:51 PM Thomas Matthijs wrote:
>
> Can reproduce your problem with java 13, so guess only 11 is currently
> supported
>
> The buildscan plugin seems to be a problem
>
> https://github.com/apache/lucene-solr/blob/gradle-master/gradle/ci/buildscan.gradle
> https://docs.gradle.com/enterprise/gradle-plugin/#connecting_to_scans_gradle_com
>
> ==> "Be careful not to commit agreement to the terms of service into a
> project that may be built by others."
>
> Looks like its only for CI builds (?) build should probably be
> disabled by default
>
> Builds seems to work with java 13 & gradle 6 with it removed:
>
> diff --git a/build.gradle b/build.gradle
> index 8e90409dde7..428d7b3e93c 100644
> --- a/build.gradle
> +++ b/build.gradle
> @@ -1,10 +1,9 @@
>
> plugins {
>id "base"
>id "com.palantir.consistent-versions" version "1.13.1"
> - id "com.gradle.build-scan" version "3.0"
>id 'de.thetaphi.forbiddenapis' version '2.7' apply false
> }
>
> // Project version and main properties. Applies to all projects.
> allprojects {
> @@ -17,13 +16,10 @@ allprojects {
> // if the build file is incorrectly written and evaluates something
> // eagerly).
>
> apply from: file('gradle/generate-defaults.gradle')
>
> -// CI systems.
> -apply from: file('gradle/ci/buildscan.gradle')
> -
> // Set up defaults and configure aspects for certain modules or functionality
> // (java, tests)
> apply from: file('gradle/defaults.gradle')
> apply from: file('gradle/defaults-java.gradle')
> apply from: file('gradle/testing/defaults-tests.gradle')
> diff --git a/gradle/validation/check-environment.gradle
> b/gradle/validation/check-environment.gradle
> index 3acfbb306d2..1d2d6e5509f 100644
> --- a/gradle/validation/check-environment.gradle
> +++ b/gradle/validation/check-environment.gradle
> @@ -3,11 +3,11 @@
>
> import org.gradle.util.GradleVersion
>
> configure(rootProject) {
>ext {
> -expectedGradleVersion = '5.6.4'
> +expectedGradleVersion = '6.0.1'
> expectedJavaVersion = JavaVersion.VERSION_11
>}
>
>wrapper {
> distributionType = Wrapper.DistributionType.ALL
> diff --git a/gradle/wrapper/gradle-wrapper.properties
> b/gradle/wrapper/gradle-wrapper.properties
> index 0ebb3108e20..1ba7206f882 100644
> --- a/gradle/wrapper/gradle-wrapper.properties
> +++ b/gradle/wrapper/gradle-wrapper.properties
> @@ -1,5 +1,5 @@
> distributionBase=GRADLE_USER_HOME
> distributionPath=wrapper/dists
> -distributionUrl=https\://services.gradle.org/distributions/gradle-5.6.4-all.zip
> +distributionUrl=https\://services.gradle.org/distributions/gradle-6.0.1-all.zip
> zipStoreBase=GRADLE_USER_HOME
> zipStorePath=wrapper/dists
>
> On Wed, 8 Jan 2020 at 16:38, Robert Muir wrote:
> >
> > right, that file is the exact one i change. the problem is if i change it
> > to 6.0.1, then it wants me to buy something.
> >
> > On Wed, Jan 8, 2020 at 10:08 AM Thomas Matthijs wrote:
> >>
> >> ./gradlew should try to use gradle 5.6.4 see
> >> ./gradle/wrapper/gradle-wrapper.properties
> >> With java 11 this all builds fine for me (can export JAVA_HOME to change)
> >> Which version of java are you using? the linked issue hints at java 13?
> >>
> >> On Wed, 8 Jan 2020 at 16:01, Robert Muir wrote:
> >> >
> >> > Here is the issue: https://github.com/gradle/gradle/issues/8681
> >> >
> >> > I tried upgrading gradle to 6.0.1, but it seems now it wants me to buy
> >> > something?
> >> >
> >> > ]$ ./gradlew help
> >> > Starting a Gradle Daemon (subsequent builds will be faster)
> >> >
> >> > FAILURE: Build failed with an exception.
> >> >
> >> > * Where:
> >> > Build file '/Users/rob.muir/eclipse.workspace/lucene-solr/build.gradle'
> >> > line: 5
> >> >
> >> > * What went wrong:
> >> > An exception occurred applying plugin request [id:
> >> > 'com.gradle.build-scan', version: '3.0']
> >> > > Failed to apply plugin [id 'com.gradle.build-scan']
> >> >> This build scan plugin is not compatible with less than Gradle 6.0.
> >> > Please use the Gradle Enterprise plugin instead.
> >> >
> >> > On Wed, Jan 8, 2020 at 9:41 AM Robert Muir wrote:
> >> >>
> >> >> I tried it out just to see, here was my experience:
> >> >>
> >> >> $ git checkout gradle-master
> >> >> Switched to branch 'gradle-master'
> >> >> Your branch is up to date with 'origin/gradle-master'.
> >> >> $ ./gradlew help
> >> >> Starting a Gradle Daemon (subsequent builds will be faster)
> >> >>
> >> >> FAILURE: Build failed with an exception.
> >> >>
> >> >> * Where:
> >> >> Settings file
> >> >> '/Users/rob.muir/eclipse.workspace/lucene-solr/settings.gradle'
> >> >>
> >> >> * What went wrong:
> >> >> Could not compile settings file
> >> >> '/Users/rob.muir/eclipse.workspace/lucene-solr/settings.gradle'.
> >> >> > startup failed:
> >> >> General error during
Re: Gradle build to land on master
> right, that file is the exact one i change. the problem is if i change it to > 6.0.1, then it wants me to buy something. You can't change to any other gradle version -- stick to the version defined in the wrapper and java 11. It is a fragile environment - switching gradle version will cause plugin incompatibilities, etc. Sigh. We can't upgrade to gradle 6.x yet because palantir's plugin for dependency management doesn't work for me then. Different JVM configurations may be rough, especially with newer JVMs. D. > On Wed, Jan 8, 2020 at 10:08 AM Thomas Matthijs wrote: >> >> ./gradlew should try to use gradle 5.6.4 see >> ./gradle/wrapper/gradle-wrapper.properties >> With java 11 this all builds fine for me (can export JAVA_HOME to change) >> Which version of java are you using? the linked issue hints at java 13? >> >> On Wed, 8 Jan 2020 at 16:01, Robert Muir wrote: >> > >> > Here is the issue: https://github.com/gradle/gradle/issues/8681 >> > >> > I tried upgrading gradle to 6.0.1, but it seems now it wants me to buy >> > something? >> > >> > ]$ ./gradlew help >> > Starting a Gradle Daemon (subsequent builds will be faster) >> > >> > FAILURE: Build failed with an exception. >> > >> > * Where: >> > Build file '/Users/rob.muir/eclipse.workspace/lucene-solr/build.gradle' >> > line: 5 >> > >> > * What went wrong: >> > An exception occurred applying plugin request [id: >> > 'com.gradle.build-scan', version: '3.0'] >> > > Failed to apply plugin [id 'com.gradle.build-scan'] >> >> This build scan plugin is not compatible with less than Gradle 6.0. >> > Please use the Gradle Enterprise plugin instead. >> > >> > On Wed, Jan 8, 2020 at 9:41 AM Robert Muir wrote: >> >> >> >> I tried it out just to see, here was my experience: >> >> >> >> $ git checkout gradle-master >> >> Switched to branch 'gradle-master' >> >> Your branch is up to date with 'origin/gradle-master'. >> >> $ ./gradlew help >> >> Starting a Gradle Daemon (subsequent builds will be faster) >> >> >> >> FAILURE: Build failed with an exception. >> >> >> >> * Where: >> >> Settings file >> >> '/Users/rob.muir/eclipse.workspace/lucene-solr/settings.gradle' >> >> >> >> * What went wrong: >> >> Could not compile settings file >> >> '/Users/rob.muir/eclipse.workspace/lucene-solr/settings.gradle'. >> >> > startup failed: >> >> General error during semantic analysis: Unsupported class file major >> >> version 57 >> >> >> >> java.lang.IllegalArgumentException: Unsupported class file major >> >> version 57 >> >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:184) >> >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:166) >> >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:152) >> >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:273) >> >> at >> >> org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:81) >> >> at >> >> org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254) >> >> at >> >> org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192) >> >> >> >> On Wed, Jan 8, 2020 at 9:30 AM Dawid Weiss wrote: >> >>> >> >>> I think the gradle-master branch is already workable enough to land on >> >>> master. >> >>> >> >>> If you're not familiar with gradle then, once merged, run "gradlew help". >> >>> >> >>> Some notes. >> >>> >> >>> 1) I have been running tests on Windows and Linux, they're ok. The >> >>> output is slightly different from ANT's but I think it's fine for >> >>> working. >> >>> >> >>> 2) The speed of compilation and running tests selectively is much >> >>> better than ant's, especially on multicore machines. >> >>> >> >>> 3) I use IntelliJ idea and the project imports into the IDE without >> >>> any special handling. Code formatting and such may need to be adjusted >> >>> though. >> >>> >> >>> 4) Some things are incomplete (precommit does a subset of checks). >> >>> Some are missing (regeneration tasks). Some are different (handling of >> >>> dependencies, build output folder locations). It will take some time >> >>> and learning to live with a new build system. I tried to provide short >> >>> guides into selective areas (they're available as help tasks or plain >> >>> text files under help/). >> >>> >> >>> 5) If something does *not* work, let me know. >> >>> >> >>> 6) It'd be nice if we had a build job somewhere on a faster machine >> >>> that would run at least "gradlew precommit check -x test" so that >> >>> rudimentary checks are applied, without running all the tests. This >> >>> would ensure consistency in dependencies, for example. >> >>> >> >>> 7) The parallel branch (gradle-master) and issue (LUCENE-9077) will be >> >>> kept open and occasionally merged back and forth. >> >>> >> >>> I have to shift more focus to my daily job but will help out and chip >> >>> at the remaining bits, time permitting. >> >>> >> >>> Dawid >> >>> >> >>>
Re: Gradle build to land on master
Can reproduce your problem with java 13, so guess only 11 is currently supported
The buildscan plugin seems to be a problem
https://github.com/apache/lucene-solr/blob/gradle-master/gradle/ci/buildscan.gradle
https://docs.gradle.com/enterprise/gradle-plugin/#connecting_to_scans_gradle_com
==> "Be careful not to commit agreement to the terms of service into a
project that may be built by others."
Looks like its only for CI builds (?) build should probably be
disabled by default
Builds seems to work with java 13 & gradle 6 with it removed:
diff --git a/build.gradle b/build.gradle
index 8e90409dde7..428d7b3e93c 100644
--- a/build.gradle
+++ b/build.gradle
@@ -1,10 +1,9 @@
plugins {
id "base"
id "com.palantir.consistent-versions" version "1.13.1"
- id "com.gradle.build-scan" version "3.0"
id 'de.thetaphi.forbiddenapis' version '2.7' apply false
}
// Project version and main properties. Applies to all projects.
allprojects {
@@ -17,13 +16,10 @@ allprojects {
// if the build file is incorrectly written and evaluates something
// eagerly).
apply from: file('gradle/generate-defaults.gradle')
-// CI systems.
-apply from: file('gradle/ci/buildscan.gradle')
-
// Set up defaults and configure aspects for certain modules or functionality
// (java, tests)
apply from: file('gradle/defaults.gradle')
apply from: file('gradle/defaults-java.gradle')
apply from: file('gradle/testing/defaults-tests.gradle')
diff --git a/gradle/validation/check-environment.gradle
b/gradle/validation/check-environment.gradle
index 3acfbb306d2..1d2d6e5509f 100644
--- a/gradle/validation/check-environment.gradle
+++ b/gradle/validation/check-environment.gradle
@@ -3,11 +3,11 @@
import org.gradle.util.GradleVersion
configure(rootProject) {
ext {
-expectedGradleVersion = '5.6.4'
+expectedGradleVersion = '6.0.1'
expectedJavaVersion = JavaVersion.VERSION_11
}
wrapper {
distributionType = Wrapper.DistributionType.ALL
diff --git a/gradle/wrapper/gradle-wrapper.properties
b/gradle/wrapper/gradle-wrapper.properties
index 0ebb3108e20..1ba7206f882 100644
--- a/gradle/wrapper/gradle-wrapper.properties
+++ b/gradle/wrapper/gradle-wrapper.properties
@@ -1,5 +1,5 @@
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
-distributionUrl=https\://services.gradle.org/distributions/gradle-5.6.4-all.zip
+distributionUrl=https\://services.gradle.org/distributions/gradle-6.0.1-all.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
On Wed, 8 Jan 2020 at 16:38, Robert Muir wrote:
>
> right, that file is the exact one i change. the problem is if i change it to
> 6.0.1, then it wants me to buy something.
>
> On Wed, Jan 8, 2020 at 10:08 AM Thomas Matthijs wrote:
>>
>> ./gradlew should try to use gradle 5.6.4 see
>> ./gradle/wrapper/gradle-wrapper.properties
>> With java 11 this all builds fine for me (can export JAVA_HOME to change)
>> Which version of java are you using? the linked issue hints at java 13?
>>
>> On Wed, 8 Jan 2020 at 16:01, Robert Muir wrote:
>> >
>> > Here is the issue: https://github.com/gradle/gradle/issues/8681
>> >
>> > I tried upgrading gradle to 6.0.1, but it seems now it wants me to buy
>> > something?
>> >
>> > ]$ ./gradlew help
>> > Starting a Gradle Daemon (subsequent builds will be faster)
>> >
>> > FAILURE: Build failed with an exception.
>> >
>> > * Where:
>> > Build file '/Users/rob.muir/eclipse.workspace/lucene-solr/build.gradle'
>> > line: 5
>> >
>> > * What went wrong:
>> > An exception occurred applying plugin request [id:
>> > 'com.gradle.build-scan', version: '3.0']
>> > > Failed to apply plugin [id 'com.gradle.build-scan']
>> >> This build scan plugin is not compatible with less than Gradle 6.0.
>> > Please use the Gradle Enterprise plugin instead.
>> >
>> > On Wed, Jan 8, 2020 at 9:41 AM Robert Muir wrote:
>> >>
>> >> I tried it out just to see, here was my experience:
>> >>
>> >> $ git checkout gradle-master
>> >> Switched to branch 'gradle-master'
>> >> Your branch is up to date with 'origin/gradle-master'.
>> >> $ ./gradlew help
>> >> Starting a Gradle Daemon (subsequent builds will be faster)
>> >>
>> >> FAILURE: Build failed with an exception.
>> >>
>> >> * Where:
>> >> Settings file
>> >> '/Users/rob.muir/eclipse.workspace/lucene-solr/settings.gradle'
>> >>
>> >> * What went wrong:
>> >> Could not compile settings file
>> >> '/Users/rob.muir/eclipse.workspace/lucene-solr/settings.gradle'.
>> >> > startup failed:
>> >> General error during semantic analysis: Unsupported class file major
>> >> version 57
>> >>
>> >> java.lang.IllegalArgumentException: Unsupported class file major
>> >> version 57
>> >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:184)
>> >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:166)
>> >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:152)
>> >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:273)
>> >> at
>> >> org.codehaus.g
Re: Gradle build to land on master
right, that file is the exact one i change. the problem is if i change it to 6.0.1, then it wants me to buy something. On Wed, Jan 8, 2020 at 10:08 AM Thomas Matthijs wrote: > ./gradlew should try to use gradle 5.6.4 see > ./gradle/wrapper/gradle-wrapper.properties > With java 11 this all builds fine for me (can export JAVA_HOME to change) > Which version of java are you using? the linked issue hints at java 13? > > On Wed, 8 Jan 2020 at 16:01, Robert Muir wrote: > > > > Here is the issue: https://github.com/gradle/gradle/issues/8681 > > > > I tried upgrading gradle to 6.0.1, but it seems now it wants me to buy > something? > > > > ]$ ./gradlew help > > Starting a Gradle Daemon (subsequent builds will be faster) > > > > FAILURE: Build failed with an exception. > > > > * Where: > > Build file '/Users/rob.muir/eclipse.workspace/lucene-solr/build.gradle' > line: 5 > > > > * What went wrong: > > An exception occurred applying plugin request [id: > 'com.gradle.build-scan', version: '3.0'] > > > Failed to apply plugin [id 'com.gradle.build-scan'] > >> This build scan plugin is not compatible with less than Gradle 6.0. > > Please use the Gradle Enterprise plugin instead. > > > > On Wed, Jan 8, 2020 at 9:41 AM Robert Muir wrote: > >> > >> I tried it out just to see, here was my experience: > >> > >> $ git checkout gradle-master > >> Switched to branch 'gradle-master' > >> Your branch is up to date with 'origin/gradle-master'. > >> $ ./gradlew help > >> Starting a Gradle Daemon (subsequent builds will be faster) > >> > >> FAILURE: Build failed with an exception. > >> > >> * Where: > >> Settings file > '/Users/rob.muir/eclipse.workspace/lucene-solr/settings.gradle' > >> > >> * What went wrong: > >> Could not compile settings file > '/Users/rob.muir/eclipse.workspace/lucene-solr/settings.gradle'. > >> > startup failed: > >> General error during semantic analysis: Unsupported class file major > version 57 > >> > >> java.lang.IllegalArgumentException: Unsupported class file major > version 57 > >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:184) > >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:166) > >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:152) > >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:273) > >> at > org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:81) > >> at > org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254) > >> at > org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192) > >> > >> On Wed, Jan 8, 2020 at 9:30 AM Dawid Weiss > wrote: > >>> > >>> I think the gradle-master branch is already workable enough to land on > master. > >>> > >>> If you're not familiar with gradle then, once merged, run "gradlew > help". > >>> > >>> Some notes. > >>> > >>> 1) I have been running tests on Windows and Linux, they're ok. The > >>> output is slightly different from ANT's but I think it's fine for > >>> working. > >>> > >>> 2) The speed of compilation and running tests selectively is much > >>> better than ant's, especially on multicore machines. > >>> > >>> 3) I use IntelliJ idea and the project imports into the IDE without > >>> any special handling. Code formatting and such may need to be adjusted > >>> though. > >>> > >>> 4) Some things are incomplete (precommit does a subset of checks). > >>> Some are missing (regeneration tasks). Some are different (handling of > >>> dependencies, build output folder locations). It will take some time > >>> and learning to live with a new build system. I tried to provide short > >>> guides into selective areas (they're available as help tasks or plain > >>> text files under help/). > >>> > >>> 5) If something does *not* work, let me know. > >>> > >>> 6) It'd be nice if we had a build job somewhere on a faster machine > >>> that would run at least "gradlew precommit check -x test" so that > >>> rudimentary checks are applied, without running all the tests. This > >>> would ensure consistency in dependencies, for example. > >>> > >>> 7) The parallel branch (gradle-master) and issue (LUCENE-9077) will be > >>> kept open and occasionally merged back and forth. > >>> > >>> I have to shift more focus to my daily job but will help out and chip > >>> at the remaining bits, time permitting. > >>> > >>> Dawid > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >>> For additional commands, e-mail: dev-h...@lucene.apache.org > >>> > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Gradle build to land on master
openjdk version "13.0.1" 2019-10-15 OpenJDK Runtime Environment AdoptOpenJDK (build 13.0.1+9) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 13.0.1+9, mixed mode, sharing) On Wed, Jan 8, 2020 at 10:08 AM Thomas Matthijs wrote: > ./gradlew should try to use gradle 5.6.4 see > ./gradle/wrapper/gradle-wrapper.properties > With java 11 this all builds fine for me (can export JAVA_HOME to change) > Which version of java are you using? the linked issue hints at java 13? > > On Wed, 8 Jan 2020 at 16:01, Robert Muir wrote: > > > > Here is the issue: https://github.com/gradle/gradle/issues/8681 > > > > I tried upgrading gradle to 6.0.1, but it seems now it wants me to buy > something? > > > > ]$ ./gradlew help > > Starting a Gradle Daemon (subsequent builds will be faster) > > > > FAILURE: Build failed with an exception. > > > > * Where: > > Build file '/Users/rob.muir/eclipse.workspace/lucene-solr/build.gradle' > line: 5 > > > > * What went wrong: > > An exception occurred applying plugin request [id: > 'com.gradle.build-scan', version: '3.0'] > > > Failed to apply plugin [id 'com.gradle.build-scan'] > >> This build scan plugin is not compatible with less than Gradle 6.0. > > Please use the Gradle Enterprise plugin instead. > > > > On Wed, Jan 8, 2020 at 9:41 AM Robert Muir wrote: > >> > >> I tried it out just to see, here was my experience: > >> > >> $ git checkout gradle-master > >> Switched to branch 'gradle-master' > >> Your branch is up to date with 'origin/gradle-master'. > >> $ ./gradlew help > >> Starting a Gradle Daemon (subsequent builds will be faster) > >> > >> FAILURE: Build failed with an exception. > >> > >> * Where: > >> Settings file > '/Users/rob.muir/eclipse.workspace/lucene-solr/settings.gradle' > >> > >> * What went wrong: > >> Could not compile settings file > '/Users/rob.muir/eclipse.workspace/lucene-solr/settings.gradle'. > >> > startup failed: > >> General error during semantic analysis: Unsupported class file major > version 57 > >> > >> java.lang.IllegalArgumentException: Unsupported class file major > version 57 > >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:184) > >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:166) > >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:152) > >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:273) > >> at > org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:81) > >> at > org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254) > >> at > org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192) > >> > >> On Wed, Jan 8, 2020 at 9:30 AM Dawid Weiss > wrote: > >>> > >>> I think the gradle-master branch is already workable enough to land on > master. > >>> > >>> If you're not familiar with gradle then, once merged, run "gradlew > help". > >>> > >>> Some notes. > >>> > >>> 1) I have been running tests on Windows and Linux, they're ok. The > >>> output is slightly different from ANT's but I think it's fine for > >>> working. > >>> > >>> 2) The speed of compilation and running tests selectively is much > >>> better than ant's, especially on multicore machines. > >>> > >>> 3) I use IntelliJ idea and the project imports into the IDE without > >>> any special handling. Code formatting and such may need to be adjusted > >>> though. > >>> > >>> 4) Some things are incomplete (precommit does a subset of checks). > >>> Some are missing (regeneration tasks). Some are different (handling of > >>> dependencies, build output folder locations). It will take some time > >>> and learning to live with a new build system. I tried to provide short > >>> guides into selective areas (they're available as help tasks or plain > >>> text files under help/). > >>> > >>> 5) If something does *not* work, let me know. > >>> > >>> 6) It'd be nice if we had a build job somewhere on a faster machine > >>> that would run at least "gradlew precommit check -x test" so that > >>> rudimentary checks are applied, without running all the tests. This > >>> would ensure consistency in dependencies, for example. > >>> > >>> 7) The parallel branch (gradle-master) and issue (LUCENE-9077) will be > >>> kept open and occasionally merged back and forth. > >>> > >>> I have to shift more focus to my daily job but will help out and chip > >>> at the remaining bits, time permitting. > >>> > >>> Dawid > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >>> For additional commands, e-mail: dev-h...@lucene.apache.org > >>> > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Gradle build to land on master
./gradlew should try to use gradle 5.6.4 see ./gradle/wrapper/gradle-wrapper.properties With java 11 this all builds fine for me (can export JAVA_HOME to change) Which version of java are you using? the linked issue hints at java 13? On Wed, 8 Jan 2020 at 16:01, Robert Muir wrote: > > Here is the issue: https://github.com/gradle/gradle/issues/8681 > > I tried upgrading gradle to 6.0.1, but it seems now it wants me to buy > something? > > ]$ ./gradlew help > Starting a Gradle Daemon (subsequent builds will be faster) > > FAILURE: Build failed with an exception. > > * Where: > Build file '/Users/rob.muir/eclipse.workspace/lucene-solr/build.gradle' line: > 5 > > * What went wrong: > An exception occurred applying plugin request [id: 'com.gradle.build-scan', > version: '3.0'] > > Failed to apply plugin [id 'com.gradle.build-scan'] >> This build scan plugin is not compatible with less than Gradle 6.0. > Please use the Gradle Enterprise plugin instead. > > On Wed, Jan 8, 2020 at 9:41 AM Robert Muir wrote: >> >> I tried it out just to see, here was my experience: >> >> $ git checkout gradle-master >> Switched to branch 'gradle-master' >> Your branch is up to date with 'origin/gradle-master'. >> $ ./gradlew help >> Starting a Gradle Daemon (subsequent builds will be faster) >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Settings file '/Users/rob.muir/eclipse.workspace/lucene-solr/settings.gradle' >> >> * What went wrong: >> Could not compile settings file >> '/Users/rob.muir/eclipse.workspace/lucene-solr/settings.gradle'. >> > startup failed: >> General error during semantic analysis: Unsupported class file major >> version 57 >> >> java.lang.IllegalArgumentException: Unsupported class file major version 57 >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:184) >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:166) >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:152) >> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:273) >> at >> org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:81) >> at >> org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254) >> at >> org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192) >> >> On Wed, Jan 8, 2020 at 9:30 AM Dawid Weiss wrote: >>> >>> I think the gradle-master branch is already workable enough to land on >>> master. >>> >>> If you're not familiar with gradle then, once merged, run "gradlew help". >>> >>> Some notes. >>> >>> 1) I have been running tests on Windows and Linux, they're ok. The >>> output is slightly different from ANT's but I think it's fine for >>> working. >>> >>> 2) The speed of compilation and running tests selectively is much >>> better than ant's, especially on multicore machines. >>> >>> 3) I use IntelliJ idea and the project imports into the IDE without >>> any special handling. Code formatting and such may need to be adjusted >>> though. >>> >>> 4) Some things are incomplete (precommit does a subset of checks). >>> Some are missing (regeneration tasks). Some are different (handling of >>> dependencies, build output folder locations). It will take some time >>> and learning to live with a new build system. I tried to provide short >>> guides into selective areas (they're available as help tasks or plain >>> text files under help/). >>> >>> 5) If something does *not* work, let me know. >>> >>> 6) It'd be nice if we had a build job somewhere on a faster machine >>> that would run at least "gradlew precommit check -x test" so that >>> rudimentary checks are applied, without running all the tests. This >>> would ensure consistency in dependencies, for example. >>> >>> 7) The parallel branch (gradle-master) and issue (LUCENE-9077) will be >>> kept open and occasionally merged back and forth. >>> >>> I have to shift more focus to my daily job but will help out and chip >>> at the remaining bits, time permitting. >>> >>> Dawid >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build to land on master
Here is the issue: https://github.com/gradle/gradle/issues/8681 I tried upgrading gradle to 6.0.1, but it seems now it wants me to buy something? ]$ ./gradlew help Starting a Gradle Daemon (subsequent builds will be faster) FAILURE: Build failed with an exception. * Where: Build file '/Users/rob.muir/eclipse.workspace/lucene-solr/build.gradle' line: 5 * What went wrong: An exception occurred applying plugin request [id: 'com.gradle.build-scan', version: '3.0'] > Failed to apply plugin [id 'com.gradle.build-scan'] > This build scan plugin is not compatible with less than Gradle 6.0. Please use the Gradle Enterprise plugin instead. On Wed, Jan 8, 2020 at 9:41 AM Robert Muir wrote: > I tried it out just to see, here was my experience: > > $ git checkout gradle-master > Switched to branch 'gradle-master' > Your branch is up to date with 'origin/gradle-master'. > $ ./gradlew help > Starting a Gradle Daemon (subsequent builds will be faster) > > FAILURE: Build failed with an exception. > > * Where: > Settings file > '/Users/rob.muir/eclipse.workspace/lucene-solr/settings.gradle' > > * What went wrong: > Could not compile settings file > '/Users/rob.muir/eclipse.workspace/lucene-solr/settings.gradle'. > > startup failed: > General error during semantic analysis: Unsupported class file major > version 57 > > java.lang.IllegalArgumentException: Unsupported class file major version > 57 > at groovyjarjarasm.asm.ClassReader.(ClassReader.java:184) > at groovyjarjarasm.asm.ClassReader.(ClassReader.java:166) > at groovyjarjarasm.asm.ClassReader.(ClassReader.java:152) > at groovyjarjarasm.asm.ClassReader.(ClassReader.java:273) > at > org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:81) > at > org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254) > at > org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192) > > On Wed, Jan 8, 2020 at 9:30 AM Dawid Weiss wrote: > >> I think the gradle-master branch is already workable enough to land on >> master. >> >> If you're not familiar with gradle then, once merged, run "gradlew help". >> >> Some notes. >> >> 1) I have been running tests on Windows and Linux, they're ok. The >> output is slightly different from ANT's but I think it's fine for >> working. >> >> 2) The speed of compilation and running tests selectively is much >> better than ant's, especially on multicore machines. >> >> 3) I use IntelliJ idea and the project imports into the IDE without >> any special handling. Code formatting and such may need to be adjusted >> though. >> >> 4) Some things are incomplete (precommit does a subset of checks). >> Some are missing (regeneration tasks). Some are different (handling of >> dependencies, build output folder locations). It will take some time >> and learning to live with a new build system. I tried to provide short >> guides into selective areas (they're available as help tasks or plain >> text files under help/). >> >> 5) If something does *not* work, let me know. >> >> 6) It'd be nice if we had a build job somewhere on a faster machine >> that would run at least "gradlew precommit check -x test" so that >> rudimentary checks are applied, without running all the tests. This >> would ensure consistency in dependencies, for example. >> >> 7) The parallel branch (gradle-master) and issue (LUCENE-9077) will be >> kept open and occasionally merged back and forth. >> >> I have to shift more focus to my daily job but will help out and chip >> at the remaining bits, time permitting. >> >> Dawid >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
Re: Gradle build to land on master
I tried it out just to see, here was my experience: $ git checkout gradle-master Switched to branch 'gradle-master' Your branch is up to date with 'origin/gradle-master'. $ ./gradlew help Starting a Gradle Daemon (subsequent builds will be faster) FAILURE: Build failed with an exception. * Where: Settings file '/Users/rob.muir/eclipse.workspace/lucene-solr/settings.gradle' * What went wrong: Could not compile settings file '/Users/rob.muir/eclipse.workspace/lucene-solr/settings.gradle'. > startup failed: General error during semantic analysis: Unsupported class file major version 57 java.lang.IllegalArgumentException: Unsupported class file major version 57 at groovyjarjarasm.asm.ClassReader.(ClassReader.java:184) at groovyjarjarasm.asm.ClassReader.(ClassReader.java:166) at groovyjarjarasm.asm.ClassReader.(ClassReader.java:152) at groovyjarjarasm.asm.ClassReader.(ClassReader.java:273) at org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:81) at org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254) at org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192) On Wed, Jan 8, 2020 at 9:30 AM Dawid Weiss wrote: > I think the gradle-master branch is already workable enough to land on > master. > > If you're not familiar with gradle then, once merged, run "gradlew help". > > Some notes. > > 1) I have been running tests on Windows and Linux, they're ok. The > output is slightly different from ANT's but I think it's fine for > working. > > 2) The speed of compilation and running tests selectively is much > better than ant's, especially on multicore machines. > > 3) I use IntelliJ idea and the project imports into the IDE without > any special handling. Code formatting and such may need to be adjusted > though. > > 4) Some things are incomplete (precommit does a subset of checks). > Some are missing (regeneration tasks). Some are different (handling of > dependencies, build output folder locations). It will take some time > and learning to live with a new build system. I tried to provide short > guides into selective areas (they're available as help tasks or plain > text files under help/). > > 5) If something does *not* work, let me know. > > 6) It'd be nice if we had a build job somewhere on a faster machine > that would run at least "gradlew precommit check -x test" so that > rudimentary checks are applied, without running all the tests. This > would ensure consistency in dependencies, for example. > > 7) The parallel branch (gradle-master) and issue (LUCENE-9077) will be > kept open and occasionally merged back and forth. > > I have to shift more focus to my daily job but will help out and chip > at the remaining bits, time permitting. > > Dawid > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Gradle build effort (respin, please read)
This may help you understand the hierarchy of how properties are shadowing each other. https://docs.gradle.org/current/userguide/build_environment.html The discussion concerning project properties that people could "override" locally concerned the settings set in the global gradle.properties file -- this was something I wasn't too happy with if they clashed with other projects. For now the gradle build doesn't have any means to populate certain properties with custom values (other than command-line). If there is a need for it we can add it. Dawid On Tue, Dec 3, 2019 at 11:48 PM Erick Erickson wrote: > > Thanks, I’m still untangling the various bits Mark put in and > relying on people who actually, you know, understand > things ;) > > > On Dec 3, 2019, at 5:11 PM, Dawid Weiss wrote: > > > >> // the project version > >> version=9.0.0 > > > > You shouldn't have it in your global configuration. In fact, only > > these make sense in there: > > > > org.gradle.daemon=true > > org.gradle.workers.max = 6 > > > > The cache and daemon settings I'd leave to the project's config. > > > > Dawid > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build effort (respin, please read)
Thanks, I’m still untangling the various bits Mark put in and relying on people who actually, you know, understand things ;) > On Dec 3, 2019, at 5:11 PM, Dawid Weiss wrote: > >> // the project version >> version=9.0.0 > > You shouldn't have it in your global configuration. In fact, only > these make sense in there: > > org.gradle.daemon=true > org.gradle.workers.max = 6 > > The cache and daemon settings I'd leave to the project's config. > > Dawid > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build effort (respin, please read)
> // the project version > version=9.0.0 You shouldn't have it in your global configuration. In fact, only these make sense in there: org.gradle.daemon=true org.gradle.workers.max = 6 The cache and daemon settings I'd leave to the project's config. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build effort (respin, please read)
Here’s what I have in ~/.gradle/gradle.properties that seems to at least be in the right ballpark. Based on Mark’s “intro to the gradle build” page: // the project version version=9.0.0 // whether or not to use the Gradle daemon - if true, keeps the build process around for reuse for up to 3 hours so that startup times are removed and hotspot has a chance to rock - you should generally set this to true in your ~/.gradle/gradle.properties // we set to false so that a CI system with no setting will not use a daemon by default org.gradle.daemon=true // allows tasks to be executed in parallel, across modules org.gradle.parallel=true // max parallel jobs to run at once, including both tasks and tests. // default is number of CPU cores which is often too high - you should start by setting it to half the number of cores, especially if you have hyperthreading org.gradle.workers.max = 6 // number of jvms to distribute tests across in parallel // defaults to number of CPU cores / 2 - you should just set this the same as org.gradle.workers.max // NOTE: gradle does not try to balance tests across jvms yet: https://github.com/gradle/gradle/issues/2669 tests_jvms = 6 // enables gradles build cache, which will reuse cached build outputs when it can org.gradle.caching=true // experimental gradle feature - does not currently work with our version constraints plugin: https://github.com/palantir/gradle-consistent-versions/pull/145 // also known to have other issues and not known to really speed anything up anyhow org.gradle.configureondemand=false // how much ram the gradle daemon or process can use org.gradle.jvmargs=-Xmx1g > On Dec 3, 2019, at 3:57 PM, Dawid Weiss wrote: > > That's aligned with my intuition -- logical cores / 2. Sadly I don't > see how we may compute the number of workers dynamically (you can do > this with test forks per project but not with the overall number of > workers). I asked about it [1]. This is perhaps one of the few > settings you could override globally via ~/.gradle/gradle.properties > because it really applies to your hardware (corrects the overestimated > default by Gradle). > > org.gradle.workers.max=[cpu cures]/2 > > D. > > [1] https://discuss.gradle.org/t/set-max-workers-dynamically/34087 > > On Tue, Dec 3, 2019 at 9:19 PM David Smiley wrote: >> >> FWIW on a 6 year old MacBook Pro with a Quad-core i7, it seems max-workers >> of 2 is about right, clocking in at 21:32. 3 took 20:17; not much better. >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> On Tue, Dec 3, 2019 at 9:13 AM Erick Erickson >> wrote: >>> >>> David Smiley: >>> >>> gradlew -p solr/packaging assemble >>> >>> couple of things: >>> 1> The place you run bin/solr from is different >>> 2> I didn’t need to specify the -p parameter and it defaulted to >>> ‘...solr/packaging/build/solr-9.0.0-SNAPSHOT', FWIW. >>> >>> Once I got over having to switch to a different dir than I was accustomed >>> to, I realized that by not mixing the build output with source, things are >>> _much_ cleaner. After a “gradlew clean”, the packaging directory only >>> contains a build.gradle file. >>> On Dec 3, 2019, at 4:48 AM, Jan Høydahl wrote: gradlew -p solr/packaging assemble >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build effort (respin, please read)
That's aligned with my intuition -- logical cores / 2. Sadly I don't see how we may compute the number of workers dynamically (you can do this with test forks per project but not with the overall number of workers). I asked about it [1]. This is perhaps one of the few settings you could override globally via ~/.gradle/gradle.properties because it really applies to your hardware (corrects the overestimated default by Gradle). org.gradle.workers.max=[cpu cures]/2 D. [1] https://discuss.gradle.org/t/set-max-workers-dynamically/34087 On Tue, Dec 3, 2019 at 9:19 PM David Smiley wrote: > > FWIW on a 6 year old MacBook Pro with a Quad-core i7, it seems max-workers of > 2 is about right, clocking in at 21:32. 3 took 20:17; not much better. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Tue, Dec 3, 2019 at 9:13 AM Erick Erickson wrote: >> >> David Smiley: >> >> gradlew -p solr/packaging assemble >> >> couple of things: >> 1> The place you run bin/solr from is different >> 2> I didn’t need to specify the -p parameter and it defaulted to >> ‘...solr/packaging/build/solr-9.0.0-SNAPSHOT', FWIW. >> >> Once I got over having to switch to a different dir than I was accustomed >> to, I realized that by not mixing the build output with source, things are >> _much_ cleaner. After a “gradlew clean”, the packaging directory only >> contains a build.gradle file. >> >> > On Dec 3, 2019, at 4:48 AM, Jan Høydahl wrote: >> > >> > gradlew -p solr/packaging assemble >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build effort (respin, please read)
FWIW on a 6 year old MacBook Pro with a Quad-core i7, it seems max-workers of 2 is about right, clocking in at 21:32. 3 took 20:17; not much better. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Tue, Dec 3, 2019 at 9:13 AM Erick Erickson wrote: > David Smiley: > > gradlew -p solr/packaging assemble > > couple of things: > 1> The place you run bin/solr from is different > 2> I didn’t need to specify the -p parameter and it defaulted to > ‘...solr/packaging/build/solr-9.0.0-SNAPSHOT', FWIW. > > Once I got over having to switch to a different dir than I was accustomed > to, I realized that by not mixing the build output with source, things are > _much_ cleaner. After a “gradlew clean”, the packaging directory only > contains a build.gradle file. > > > On Dec 3, 2019, at 4:48 AM, Jan Høydahl wrote: > > > > gradlew -p solr/packaging assemble > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Gradle build effort (respin, please read)
David Smiley: gradlew -p solr/packaging assemble couple of things: 1> The place you run bin/solr from is different 2> I didn’t need to specify the -p parameter and it defaulted to ‘...solr/packaging/build/solr-9.0.0-SNAPSHOT', FWIW. Once I got over having to switch to a different dir than I was accustomed to, I realized that by not mixing the build output with source, things are _much_ cleaner. After a “gradlew clean”, the packaging directory only contains a build.gradle file. > On Dec 3, 2019, at 4:48 AM, Jan Høydahl wrote: > > gradlew -p solr/packaging assemble - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build effort (respin, please read)
Here's an example why I think toying with this gradle build is fun. This adds a build fragment that cleans up the application of forbidden API rules (they're applied automatically when a module consumes a certain dependency). Note how this is isolated from everything else, yet cross-cuts across all modules to apply it consistently and without too much boilerplate. https://github.com/apache/lucene-solr/commit/6461909129c806a8c71d5e4d053061640fce4554 Dawid D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build effort (respin, please read)
> Great work Dawid. Just trying out solr tests now. A full suite of solr and lucene takes ~50 minutes... And I think it's pretty much the same with ant now (?). > I see that it is not very smart in parallel scheduling. But that is probably > something we can improve over time? Maybe. I don't think it's going to improve things significantly though. It'd take some deeper restructuring of the codebase to get them to run faster. > Is there some env.var or global setting to force e.g. -Ptests.seed=deadbeef > for faster runs? Fixing the seed should be only done if you want to run two consecutive times with exactly the same combination of components. Don't fix it locally forever, please. Those randomizations are really effective to discover odd stuff (even at the JVM bugs level...). > We probably don’t need to randomize everything everywhere every time? Perhaps some of the stuff we do statically at test suite level (LuceneTestCase etc.) is too eager... I didn't look into this. But overall I disagree with Mark here -- I still have faith in that randomization of components has value to it. > Also, I like your moving of build files from the source tree. Will soon get > used to gradlew -p solr/packaging assemble. > Wonder how this will work with Admin UI changes. Hopefully you can just run a > new assemble and reload browser on each change. If you wish to rerun assembly with a server running in the background it may be tricky because some files may be locked by live processes (applies to Windows in particular) and some files generated by the server (logs, etc.) may be removed by the sync (since it's a sync, not a copy). Working on "live" files served via http is indeed going to be tricky. You could always work on those files inside the assembled distribution and copy them over to the sources once done... not a solution but a workaround. D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build effort (respin, please read)
> ./gradlew -p lucene cleanTest test -Ptests.seed=28BC12BA7C2CD894 > --max-workers=4 > > the build time is XXX. Yeah... you can tell I'm a non-linear e-mail writer, huh? s/XXX/11m 43s/. For what it's worth, the "ant test" on Lucene takes an even longer time on that machine: BUILD SUCCESSFUL Total time: 14 minutes 1 second And I think it's a similar situation with Solr tests (I checked a while ago, didn't try now). Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build effort (respin, please read)
Great work Dawid. Just trying out solr tests now. I see that it is not very smart in parallel scheduling. But that is probably something we can improve over time? Is there some env.var or global setting to force e.g. -Ptests.seed=deadbeef for faster runs? We probably don’t need to randomize everything everywhere every time? Also, I like your moving of build files from the source tree. Will soon get used to gradlew -p solr/packaging assemble. Wonder how this will work with Admin UI changes. Hopefully you can just run a new assemble and reload browser on each change. Jan > 3. des. 2019 kl. 09:35 skrev Dawid Weiss : > >> gradlew -p lucene test >> That took my machine 27 minutes! I can see it used like 7 threads when I'd >> rather it use 3-4. That's probably why. > > I capped the execution of parallel tests to this > (gradle/testing/defaults-tests.gradle): > > // Set up default parallel execution limits. > maxParallelForks = (int) Math.max(1, > Math.min(Runtime.runtime.availableProcessors() / 2.0, 3.0)) > > but this limit applies per-project and gradle runs with N workers in > parallel mode (where N equals the number of cores). For example, on my > 8-core Linux machine (SSD drive) the test time for > > ./gradlew -p lucene cleanTest test -Ptests.seed=28BC12BA7C2CD894 > > is 11m 32s. If I limit max workers to 4: > > ./gradlew -p lucene cleanTest test -Ptests.seed=28BC12BA7C2CD894 > --max-workers=4 > > the build time is XXX. > > It is obvious we need to fine-tune this but it's not obvious what the > defaults should be because there are many dimensions to performance: > I/O congestion, CPU cores, overall memory bandwidth and operating > system (underlying filesystem implementation mostly, I believe). Also, > as Mark pointed out before, the test runner is slightly different in > Gradle and doesn't load-balance tests too efficiently (no work > stealing). > > Finally, all the above also doesn't mean we can only think of > improving gradle performance and not tests themselves... Some of them > are just (very) slow. :) > > If you're willing to experiment then try to run with a varying number > of workers (and identical seed to keep the tests the same). Then see > which one turns out to be the best for you (and report back). I think > it'll be half the number of cores (effectively physical cores) unless > you have a very beefy machine when memory bandwidth and I/O comes into > play. > > gradlew --max-workers N -Ptests.seed=deadbeef > >> gradlew :helpAnt >> This failed: -- java.io.FileNotFoundException > > Corrected, apologies. > > Dawid > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build effort (respin, please read)
> gradlew -p lucene test > That took my machine 27 minutes! I can see it used like 7 threads when I'd > rather it use 3-4. That's probably why. I capped the execution of parallel tests to this (gradle/testing/defaults-tests.gradle): // Set up default parallel execution limits. maxParallelForks = (int) Math.max(1, Math.min(Runtime.runtime.availableProcessors() / 2.0, 3.0)) but this limit applies per-project and gradle runs with N workers in parallel mode (where N equals the number of cores). For example, on my 8-core Linux machine (SSD drive) the test time for ./gradlew -p lucene cleanTest test -Ptests.seed=28BC12BA7C2CD894 is 11m 32s. If I limit max workers to 4: ./gradlew -p lucene cleanTest test -Ptests.seed=28BC12BA7C2CD894 --max-workers=4 the build time is XXX. It is obvious we need to fine-tune this but it's not obvious what the defaults should be because there are many dimensions to performance: I/O congestion, CPU cores, overall memory bandwidth and operating system (underlying filesystem implementation mostly, I believe). Also, as Mark pointed out before, the test runner is slightly different in Gradle and doesn't load-balance tests too efficiently (no work stealing). Finally, all the above also doesn't mean we can only think of improving gradle performance and not tests themselves... Some of them are just (very) slow. :) If you're willing to experiment then try to run with a varying number of workers (and identical seed to keep the tests the same). Then see which one turns out to be the best for you (and report back). I think it'll be half the number of cores (effectively physical cores) unless you have a very beefy machine when memory bandwidth and I/O comes into play. gradlew --max-workers N -Ptests.seed=deadbeef > gradlew :helpAnt > This failed: -- java.io.FileNotFoundException Corrected, apologies. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build effort (respin, please read)
Really impressive Dawid! I like how you were able to organize the build files, especially the hacks and keeping the build.gradle files relatively straightforward. The dependency approach is totally good with me. It addresses the essential problem with pure Maven which is unknowingly sucking in transitive dependencies. Code reviews will continue to make new/updated dependencies visible as they are today by forcing the commit to include checksums 'n such. gradlew -p lucene test That took my machine 27 minutes! I can see it used like 7 threads when I'd rather it use 3-4. That's probably why. gradlew :helpAnt This failed: -- java.io.FileNotFoundException: /Users/dsmiley/DevSearch/lucene-solr/help/ant-gradle.txt (No such file or directory)seems like a simple error related to an incomplete rename or other refactor What gradlew command is the equivalent of "ant server" for Solr? I wish to use "bin/solr". I'm +1 with you committing to master as soon as you are comfortable. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Mon, Dec 2, 2019 at 11:36 AM Dawid Weiss wrote: > > - run a single unit test (NOTE: one of the TODO’s is running the test > multiple times. Gradle defaults to marking a test as “good” once it passes > and doesn’t re-run it until there are code changes. This can be fixed) > > See gradlew :helpTests, Erick -- I corrected some of it today. In short: > > You can already run a single test multiple times with tests.iters > (passed via -P or -D). This works from IDEs as well (because it's the > runner's code, not gradle). Full 'beasting' mode is more difficult > because current working directories will overlap. I have some ideas > how this can be solved. > > I don't think we should force tests to re-run if nothing has changed. > If everything is up-to-date and no properties have changed, the tests > should skip. It really helps with incremental runs. Please note that > "nothing has changed" is tricky with gradle because it takes all the > properties, arguments, etc. passed to the test runner as input -- we > pick a random test seed on each run so tests should re-run > automatically because the seed will be different. However, if you run > the same seed multiple times over (gradlew test -Ptests.seed=deadbeef) > then it will indeed skip them. Finally, if you wish to force a re-run > of any task gradle gives you many options to do so (the simplest is to > add a forced "cleanXXX" of a task named XXX - try it: gradlew > cleanTest test -Ptests.seed=deadbeef). > > I will add this explanation to the tests help file. > > I've warned gradle can be frustratingly complex! (but once you learn > it it's fun ;). > > D. > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Gradle build effort (respin, please read)
> - run a single unit test (NOTE: one of the TODO’s is running the test > multiple times. Gradle defaults to marking a test as “good” once it passes > and doesn’t re-run it until there are code changes. This can be fixed) See gradlew :helpTests, Erick -- I corrected some of it today. In short: You can already run a single test multiple times with tests.iters (passed via -P or -D). This works from IDEs as well (because it's the runner's code, not gradle). Full 'beasting' mode is more difficult because current working directories will overlap. I have some ideas how this can be solved. I don't think we should force tests to re-run if nothing has changed. If everything is up-to-date and no properties have changed, the tests should skip. It really helps with incremental runs. Please note that "nothing has changed" is tricky with gradle because it takes all the properties, arguments, etc. passed to the test runner as input -- we pick a random test seed on each run so tests should re-run automatically because the seed will be different. However, if you run the same seed multiple times over (gradlew test -Ptests.seed=deadbeef) then it will indeed skip them. Finally, if you wish to force a re-run of any task gradle gives you many options to do so (the simplest is to add a forced "cleanXXX" of a task named XXX - try it: gradlew cleanTest test -Ptests.seed=deadbeef). I will add this explanation to the tests help file. I've warned gradle can be frustratingly complex! (but once you learn it it's fun ;). D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build effort (respin, please read)
First, a slight correction. I deserve very little credit here, Dawid did the heavy lifting, a huge shout-out to him! Cheering from the sidelines is easy ;) I played around a little with this last night, and AFAIC let’s just fold it into master. From my perspective, it’s important that we be able to try using this in baby steps, falling back to ant whenever there’s something we can’t do in Gradle (yet). Having more people contribute now that it’s functional will speed this process. Last night I was able to: - build Solr - run a single unit test (NOTE: one of the TODO’s is running the test multiple times. Gradle defaults to marking a test as “good” once it passes and doesn’t re-run it until there are code changes. This can be fixed) - run the full test suite - start solr with bin/solr start… (NOTE: this is in a slightly different place now) - start Solr and attach a debugger and hit breakpoints. IOW, I can do my regular work just using Gradle. +1 to merging with master. About merging into 8x. Straw-man proposal: we don’t. There are going to be a zillion commits on this before we stop using Ant, and merging into 8x after they’re all done will be “interesting”. So I propose we target 9.0 for using Gradle rather than Ant and do _NOT_ merge any of this into 8x. If the Gradle build isn’t ready by the time 9.0 comes out, we can still use Ant and switch over later. > On Dec 2, 2019, at 10:07 AM, Dawid Weiss wrote: > > Hi folks. > > For those who prefer the short version: > git clone https://gitbox.apache.org/repos/asf/lucene-solr.git -b gradle-master > gradlew :help > gradlew -p lucene test > gradlew -p solr/packaging assemble > > A longer explanation follows. > > I realize many of you probably got tired of the discussions and issues > concerning the gradle build. I don't know why this turned so awkward > instead of exciting (which it is) but I wanted to try to reflect on > the lessons learned and retry the effort, perhaps with a better > outcome this time. > > Erick and I spent some time trying to revive what Mark did but we > failed -- there were just too many mixed concerns and work-in-progress > changes to reconcile. I wanted something that would be: > > - usable from the first minute, > - simple (no custom gradle plugins, etc.), > - divisible into smaller logical chunks so that contributions could be > smaller and incremental; without the need to work on the whole thing > for months, > - backward compatible with ant (because we are forced to use it until > everything is ported). > > I took some of the things from Cao and Mark but I essentially rewrote > the build file and split it into logical fragments that configure > different build aspects: > > https://github.com/apache/lucene-solr/blob/gradle-master/build.gradle#L18-L48 > > A good example of the "smaller fragment" approach is a developer aid > to display the slowest tests at the end of the run -- it's > self-contained and gracefully separated from anything else in the > build: > > https://github.com/apache/lucene-solr/blob/gradle-master/gradle/testing/slowest-tests-at-end.gradle > > It was, in fact, possible to isolate all the sore points and problems > present with the current ant-based build into separate files that > provide "workarounds" or "hacks" so that gradle works on the same file > structure as ant. All of these files indicate a potential problem with > the build itself (dependencies on test classes, non-conventional > folder naming, etc.) but until we get rid of ant we can't easily fix > these: > > https://github.com/apache/lucene-solr/tree/gradle-master/gradle/ant-compat > > The gradle-master branch is essentially a fork from the master branch > with gradle build files layered on top. My (most controversial) > decision was to embrace transitive dependencies -- I agree with Mark > that they just can't be managed manually anymore, especially for Solr. > Gradle has vast possibilities of excluding and configuring > dependencies in any way we like without the need to enumerate each and > every package manually. When something is added for the first time or > upgraded we will have a safety trigger of the lock file and jar > checksums (I still need to add this particular section though). > > The build works for me just fine: tests run, assembly works, solr > packaging works. IntelliJ imports the project as it is, without any > need for custom tuning. > > The question is how do we proceed from here. I can merge master fairly > often but I think it would make most sense if we folded this in to > master _as soon as possible_ so that people start doing actual > development using gradle (and provide real life feedback). Please > shout out if you have something against it. > > In the meantime, if you're familiar with gradle and would like to help > then here is a list of things that are missing from the build: > https://issues.apache.org/jira/browse/LUCENE-9077 > > Some of them are simple, some are more difficult. The
Re: Gradle build
if for no other reason than to standardise on a sane trunk everyone can work on +1 for backport to 8 From: Erick Erickson Sent: Saturday, November 9, 2019 10:41 AM To: dev@lucene.apache.org Subject: Re: Gradle build OK, see SOLR-13914. I figure to close SOLR-13452 after I push to master, it’s too long. To Cassandra’s point: I fully sympathize for two reasons: 1> the more we all can use Gradle all the time, the faster it’ll get into its final shape 2> the longer we have to add patches, the harder it’ll be to backport Therefore I’m going to push for back-porting Real Soon Now, next weekend if possible. As soon as we have evidence that the Gradle build doesn’t break Solr, i.e. Jenkins master builds using Ant don’t start breaking due to this, I propose to back-port to 8x. Let the fun begin! Erick > On Nov 8, 2019, at 8:30 PM, Gus Heck wrote: > > +1 to option 2 > > On Thu, Nov 7, 2019 at 6:23 PM David Smiley wrote: > > Doing 2 doesn’t stop us going to 3 soon if we want. Easier to fix/improve on > one branch while it’s new. > > On Thu, Nov 7, 2019 at 5:41 PM Adrien Grand wrote: > I'd be fine with option 2 but I have a slight preference for option 3. > If we see the Gradle build as the future default build, then we need > to start using it and I wonder that having to use a different workflow > on branch_8x would be an incentive to keep using the Ant build > instead. > > On Thu, Nov 7, 2019 at 11:15 AM Cassandra Targett > wrote: > > > > I’m fine with Option 2. > > > > Putting my project manager hat on, I’d really like to see a central list or > > Jira issues of the things we want to make sure to do before we can turn off > > Ant. The list/sub-tasks could be compiled after it’s merged to master, but > > it would be nice if we could approach this in a coordinated way so we’re > > all able to figure out quickly what remains - I think we’ll have a higher > > chance of faster success that way. Hopefully also people would sign up for > > the things that they will volunteer to drive to completion instead of > > hanging back because they aren’t sure what needs to be done. > > > > Dawid and I worked on the Ref Guide transition to Gradle in a separate > > branch and it’s either finished or very close to it IMO. It includes the PR > > I put up last night to remove the PDF build tasks. I just need to merge it > > into the main Gradle branch (jira/SOLR-13452_gradle_8), which I will try to > > do by tomorrow. > > > > Cassandra > > On Nov 6, 2019, 3:07 PM -0600, David Smiley , > > wrote: > > > > Option 2. > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > > > > On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson > > wrote: > >> > >> All: > >> > >> re: SOLR-13452. I’m now coming down on both sides of the issue. My motive > >> here is if this was pushed, even in its current incomplete state, people > >> would have an easier time contributing to the effort. Of course this means > >> I would be asking people to use the gradle build at least on master if at > >> all possible. > >> > >> There are several assumptions I’m making here: > >> > >> - we can keep running the Ant build as long as necessary. Ant would be our > >> primary build process. The purpose of pushing the current Gradle effort is > >> to make it easier for others to contribute and “just try it”. > >> > >> - There are no conflicts between the Gradle and Ant builds, so we can > >> continue to use Ant as necessary until we make the switch. > >> > >> - people will commit up front to putting some effort into this. I flat > >> guarantee I won’t carry the load alone. If nobody else steps up, I’ll > >> table it. I will volunteer to push fixes from non-committers. > >> — Yes, people can do this already with the gradle_8 branch, it’d just be > >> easier if it was already in the pull. > >> > >> - moving to Gradle as our primary workflow won’t happen until we work out > >> some of the kinks, things like. > >> — running on Jenkins. > >> — Getting the equivalent of “ant server dist” to run. > >> — Getting the ref guide built. > >> — I’m sure other things will crop up. > >> > >> > >> So there are several options, please let me know which one you prefer: > >> > >> 1. do nothing. People can check out the gradle_8 build and work on it. > >> There has been some of this so far, many tha
Re: Gradle build
I hoped to push my Ref Guide changes to the gradle_8 branch yesterday but got distracted with some other stuff for work. I don’t expect I’ll have time to work on it this weekend so if you push the other bits to master this weekend, I’ll make a new branch off master and will hopefully be able to get it in quickly early next week (I’m traveling Tuesday-Friday, so we’ll see). Cassandra On Nov 9, 2019, 9:41 AM -0600, Erick Erickson , wrote: > OK, see SOLR-13914. I figure to close SOLR-13452 after I push to master, it’s > too long. > > To Cassandra’s point: I fully sympathize for two reasons: > > 1> the more we all can use Gradle all the time, the faster it’ll get into its > final shape > > 2> the longer we have to add patches, the harder it’ll be to backport > > Therefore I’m going to push for back-porting Real Soon Now, next weekend if > possible. As soon as we have evidence that the Gradle build doesn’t break > Solr, i.e. Jenkins master builds using Ant don’t start breaking due to this, > I propose to back-port to 8x. > > Let the fun begin! > > Erick > > > On Nov 8, 2019, at 8:30 PM, Gus Heck wrote: > > > > +1 to option 2 > > > > On Thu, Nov 7, 2019 at 6:23 PM David Smiley > > wrote: > > > > Doing 2 doesn’t stop us going to 3 soon if we want. Easier to fix/improve > > on one branch while it’s new. > > > > On Thu, Nov 7, 2019 at 5:41 PM Adrien Grand wrote: > > I'd be fine with option 2 but I have a slight preference for option 3. > > If we see the Gradle build as the future default build, then we need > > to start using it and I wonder that having to use a different workflow > > on branch_8x would be an incentive to keep using the Ant build > > instead. > > > > On Thu, Nov 7, 2019 at 11:15 AM Cassandra Targett > > wrote: > > > > > > I’m fine with Option 2. > > > > > > Putting my project manager hat on, I’d really like to see a central list > > > or Jira issues of the things we want to make sure to do before we can > > > turn off Ant. The list/sub-tasks could be compiled after it’s merged to > > > master, but it would be nice if we could approach this in a coordinated > > > way so we’re all able to figure out quickly what remains - I think we’ll > > > have a higher chance of faster success that way. Hopefully also people > > > would sign up for the things that they will volunteer to drive to > > > completion instead of hanging back because they aren’t sure what needs to > > > be done. > > > > > > Dawid and I worked on the Ref Guide transition to Gradle in a separate > > > branch and it’s either finished or very close to it IMO. It includes the > > > PR I put up last night to remove the PDF build tasks. I just need to > > > merge it into the main Gradle branch (jira/SOLR-13452_gradle_8), which I > > > will try to do by tomorrow. > > > > > > Cassandra > > > On Nov 6, 2019, 3:07 PM -0600, David Smiley , > > > wrote: > > > > > > Option 2. > > > > > > ~ David Smiley > > > Apache Lucene/Solr Search Developer > > > http://www.linkedin.com/in/davidwsmiley > > > > > > > > > On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson > > > wrote: > > > > > > > > All: > > > > > > > > re: SOLR-13452. I’m now coming down on both sides of the issue. My > > > > motive here is if this was pushed, even in its current incomplete > > > > state, people would have an easier time contributing to the effort. Of > > > > course this means I would be asking people to use the gradle build at > > > > least on master if at all possible. > > > > > > > > There are several assumptions I’m making here: > > > > > > > > - we can keep running the Ant build as long as necessary. Ant would be > > > > our primary build process. The purpose of pushing the current Gradle > > > > effort is to make it easier for others to contribute and “just try it”. > > > > > > > > - There are no conflicts between the Gradle and Ant builds, so we can > > > > continue to use Ant as necessary until we make the switch. > > > > > > > > - people will commit up front to putting some effort into this. I flat > > > > guarantee I won’t carry the load alone. If nobody else steps up, I’ll > > > > table it. I will volunteer to push fixes from non-committers. > > > > — Yes, people can do this already with the gradle_8 branch, it’d just > > > > be easier if it was already in the pull. > > > > > > > > - moving to Gradle as our primary workflow won’t happen until we work > > > > out some of the kinks, things like. > > > > — running on Jenkins. > > > > — Getting the equivalent of “ant server dist” to run. > > > > — Getting the ref guide built. > > > > — I’m sure other things will crop up. > > > > > > > > > > > > So there are several options, please let me know which one you prefer: > > > > > > > > 1. do nothing. People can check out the gradle_8 build and work on it. > > > > There has been some of this so far, many thanks. > > > > > > > > 2. merge it into master only. TBD is when we take Ant out of master. > > > > > > > > 3. merge into both master and 8
Re: Gradle build
OK, see SOLR-13914. I figure to close SOLR-13452 after I push to master, it’s too long. To Cassandra’s point: I fully sympathize for two reasons: 1> the more we all can use Gradle all the time, the faster it’ll get into its final shape 2> the longer we have to add patches, the harder it’ll be to backport Therefore I’m going to push for back-porting Real Soon Now, next weekend if possible. As soon as we have evidence that the Gradle build doesn’t break Solr, i.e. Jenkins master builds using Ant don’t start breaking due to this, I propose to back-port to 8x. Let the fun begin! Erick > On Nov 8, 2019, at 8:30 PM, Gus Heck wrote: > > +1 to option 2 > > On Thu, Nov 7, 2019 at 6:23 PM David Smiley wrote: > > Doing 2 doesn’t stop us going to 3 soon if we want. Easier to fix/improve on > one branch while it’s new. > > On Thu, Nov 7, 2019 at 5:41 PM Adrien Grand wrote: > I'd be fine with option 2 but I have a slight preference for option 3. > If we see the Gradle build as the future default build, then we need > to start using it and I wonder that having to use a different workflow > on branch_8x would be an incentive to keep using the Ant build > instead. > > On Thu, Nov 7, 2019 at 11:15 AM Cassandra Targett > wrote: > > > > I’m fine with Option 2. > > > > Putting my project manager hat on, I’d really like to see a central list or > > Jira issues of the things we want to make sure to do before we can turn off > > Ant. The list/sub-tasks could be compiled after it’s merged to master, but > > it would be nice if we could approach this in a coordinated way so we’re > > all able to figure out quickly what remains - I think we’ll have a higher > > chance of faster success that way. Hopefully also people would sign up for > > the things that they will volunteer to drive to completion instead of > > hanging back because they aren’t sure what needs to be done. > > > > Dawid and I worked on the Ref Guide transition to Gradle in a separate > > branch and it’s either finished or very close to it IMO. It includes the PR > > I put up last night to remove the PDF build tasks. I just need to merge it > > into the main Gradle branch (jira/SOLR-13452_gradle_8), which I will try to > > do by tomorrow. > > > > Cassandra > > On Nov 6, 2019, 3:07 PM -0600, David Smiley , > > wrote: > > > > Option 2. > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > > > > On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson > > wrote: > >> > >> All: > >> > >> re: SOLR-13452. I’m now coming down on both sides of the issue. My motive > >> here is if this was pushed, even in its current incomplete state, people > >> would have an easier time contributing to the effort. Of course this means > >> I would be asking people to use the gradle build at least on master if at > >> all possible. > >> > >> There are several assumptions I’m making here: > >> > >> - we can keep running the Ant build as long as necessary. Ant would be our > >> primary build process. The purpose of pushing the current Gradle effort is > >> to make it easier for others to contribute and “just try it”. > >> > >> - There are no conflicts between the Gradle and Ant builds, so we can > >> continue to use Ant as necessary until we make the switch. > >> > >> - people will commit up front to putting some effort into this. I flat > >> guarantee I won’t carry the load alone. If nobody else steps up, I’ll > >> table it. I will volunteer to push fixes from non-committers. > >> — Yes, people can do this already with the gradle_8 branch, it’d just be > >> easier if it was already in the pull. > >> > >> - moving to Gradle as our primary workflow won’t happen until we work out > >> some of the kinks, things like. > >> — running on Jenkins. > >> — Getting the equivalent of “ant server dist” to run. > >> — Getting the ref guide built. > >> — I’m sure other things will crop up. > >> > >> > >> So there are several options, please let me know which one you prefer: > >> > >> 1. do nothing. People can check out the gradle_8 build and work on it. > >> There has been some of this so far, many thanks. > >> > >> 2. merge it into master only. TBD is when we take Ant out of master. > >> > >> 3. merge into both master and 8x. Assuming we can continue to use both, > >> I’m not sure what advantage there is to merging into 8x. This seems like > >> something that should come along with a major version release. > >> > >> 4. wait until it’s feature-complete. Based on the evidence so far, this > >> may be a long time coming. > >> > >> Also, the timing is fungible. I don’t see a downside as long as we can > >> continue to build with Ant. I certainly _do_ see a downside if we have to > >> do everything Ant does immediately after pushing to whatever branches. > >> > >> Erick > >> > >> > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@lu
Re: Gradle build
+1 to option 2 On Thu, Nov 7, 2019 at 6:23 PM David Smiley wrote: > > Doing 2 doesn’t stop us going to 3 soon if we want. Easier to fix/improve > on one branch while it’s new. > > On Thu, Nov 7, 2019 at 5:41 PM Adrien Grand wrote: > >> I'd be fine with option 2 but I have a slight preference for option 3. >> If we see the Gradle build as the future default build, then we need >> to start using it and I wonder that having to use a different workflow >> on branch_8x would be an incentive to keep using the Ant build >> instead. >> >> On Thu, Nov 7, 2019 at 11:15 AM Cassandra Targett >> wrote: >> > >> > I’m fine with Option 2. >> > >> > Putting my project manager hat on, I’d really like to see a central >> list or Jira issues of the things we want to make sure to do before we can >> turn off Ant. The list/sub-tasks could be compiled after it’s merged to >> master, but it would be nice if we could approach this in a coordinated way >> so we’re all able to figure out quickly what remains - I think we’ll have a >> higher chance of faster success that way. Hopefully also people would sign >> up for the things that they will volunteer to drive to completion instead >> of hanging back because they aren’t sure what needs to be done. >> > >> > Dawid and I worked on the Ref Guide transition to Gradle in a separate >> branch and it’s either finished or very close to it IMO. It includes the PR >> I put up last night to remove the PDF build tasks. I just need to merge it >> into the main Gradle branch (jira/SOLR-13452_gradle_8), which I will try to >> do by tomorrow. >> > >> > Cassandra >> > On Nov 6, 2019, 3:07 PM -0600, David Smiley , >> wrote: >> > >> > Option 2. >> > >> > ~ David Smiley >> > Apache Lucene/Solr Search Developer >> > http://www.linkedin.com/in/davidwsmiley >> > >> > >> > On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson >> wrote: >> >> >> >> All: >> >> >> >> re: SOLR-13452. I’m now coming down on both sides of the issue. My >> motive here is if this was pushed, even in its current incomplete state, >> people would have an easier time contributing to the effort. Of course this >> means I would be asking people to use the gradle build at least on master >> if at all possible. >> >> >> >> There are several assumptions I’m making here: >> >> >> >> - we can keep running the Ant build as long as necessary. Ant would be >> our primary build process. The purpose of pushing the current Gradle effort >> is to make it easier for others to contribute and “just try it”. >> >> >> >> - There are no conflicts between the Gradle and Ant builds, so we can >> continue to use Ant as necessary until we make the switch. >> >> >> >> - people will commit up front to putting some effort into this. I flat >> guarantee I won’t carry the load alone. If nobody else steps up, I’ll table >> it. I will volunteer to push fixes from non-committers. >> >> — Yes, people can do this already with the gradle_8 branch, it’d just >> be easier if it was already in the pull. >> >> >> >> - moving to Gradle as our primary workflow won’t happen until we work >> out some of the kinks, things like. >> >> — running on Jenkins. >> >> — Getting the equivalent of “ant server dist” to run. >> >> — Getting the ref guide built. >> >> — I’m sure other things will crop up. >> >> >> >> >> >> So there are several options, please let me know which one you prefer: >> >> >> >> 1. do nothing. People can check out the gradle_8 build and work on it. >> There has been some of this so far, many thanks. >> >> >> >> 2. merge it into master only. TBD is when we take Ant out of master. >> >> >> >> 3. merge into both master and 8x. Assuming we can continue to use >> both, I’m not sure what advantage there is to merging into 8x. This seems >> like something that should come along with a major version release. >> >> >> >> 4. wait until it’s feature-complete. Based on the evidence so far, >> this may be a long time coming. >> >> >> >> Also, the timing is fungible. I don’t see a downside as long as we can >> continue to build with Ant. I certainly _do_ see a downside if we have to >> do everything Ant does immediately after pushing to whatever branches. >> >> >> >> Erick >> >> >> >> >> >> >> >> >> >> - >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> >> >> -- >> Adrien >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> -- > Sent from Gmail Mobile > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
Re: Gradle build
Doing 2 doesn’t stop us going to 3 soon if we want. Easier to fix/improve on one branch while it’s new. On Thu, Nov 7, 2019 at 5:41 PM Adrien Grand wrote: > I'd be fine with option 2 but I have a slight preference for option 3. > If we see the Gradle build as the future default build, then we need > to start using it and I wonder that having to use a different workflow > on branch_8x would be an incentive to keep using the Ant build > instead. > > On Thu, Nov 7, 2019 at 11:15 AM Cassandra Targett > wrote: > > > > I’m fine with Option 2. > > > > Putting my project manager hat on, I’d really like to see a central list > or Jira issues of the things we want to make sure to do before we can turn > off Ant. The list/sub-tasks could be compiled after it’s merged to master, > but it would be nice if we could approach this in a coordinated way so > we’re all able to figure out quickly what remains - I think we’ll have a > higher chance of faster success that way. Hopefully also people would sign > up for the things that they will volunteer to drive to completion instead > of hanging back because they aren’t sure what needs to be done. > > > > Dawid and I worked on the Ref Guide transition to Gradle in a separate > branch and it’s either finished or very close to it IMO. It includes the PR > I put up last night to remove the PDF build tasks. I just need to merge it > into the main Gradle branch (jira/SOLR-13452_gradle_8), which I will try to > do by tomorrow. > > > > Cassandra > > On Nov 6, 2019, 3:07 PM -0600, David Smiley , > wrote: > > > > Option 2. > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > > > > On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson > wrote: > >> > >> All: > >> > >> re: SOLR-13452. I’m now coming down on both sides of the issue. My > motive here is if this was pushed, even in its current incomplete state, > people would have an easier time contributing to the effort. Of course this > means I would be asking people to use the gradle build at least on master > if at all possible. > >> > >> There are several assumptions I’m making here: > >> > >> - we can keep running the Ant build as long as necessary. Ant would be > our primary build process. The purpose of pushing the current Gradle effort > is to make it easier for others to contribute and “just try it”. > >> > >> - There are no conflicts between the Gradle and Ant builds, so we can > continue to use Ant as necessary until we make the switch. > >> > >> - people will commit up front to putting some effort into this. I flat > guarantee I won’t carry the load alone. If nobody else steps up, I’ll table > it. I will volunteer to push fixes from non-committers. > >> — Yes, people can do this already with the gradle_8 branch, it’d just > be easier if it was already in the pull. > >> > >> - moving to Gradle as our primary workflow won’t happen until we work > out some of the kinks, things like. > >> — running on Jenkins. > >> — Getting the equivalent of “ant server dist” to run. > >> — Getting the ref guide built. > >> — I’m sure other things will crop up. > >> > >> > >> So there are several options, please let me know which one you prefer: > >> > >> 1. do nothing. People can check out the gradle_8 build and work on it. > There has been some of this so far, many thanks. > >> > >> 2. merge it into master only. TBD is when we take Ant out of master. > >> > >> 3. merge into both master and 8x. Assuming we can continue to use both, > I’m not sure what advantage there is to merging into 8x. This seems like > something that should come along with a major version release. > >> > >> 4. wait until it’s feature-complete. Based on the evidence so far, this > may be a long time coming. > >> > >> Also, the timing is fungible. I don’t see a downside as long as we can > continue to build with Ant. I certainly _do_ see a downside if we have to > do everything Ant does immediately after pushing to whatever branches. > >> > >> Erick > >> > >> > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > > -- > Adrien > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Sent from Gmail Mobile
Re: Gradle build
+1 to option 2 to begin with. I don’t know if we need to wait for a major release for this change, but I think it may be easier to iterate while it’s only in master for a while. > On Nov 7, 2019, at 2:41 PM, Adrien Grand wrote: > > I'd be fine with option 2 but I have a slight preference for option 3. > If we see the Gradle build as the future default build, then we need > to start using it and I wonder that having to use a different workflow > on branch_8x would be an incentive to keep using the Ant build > instead. > > On Thu, Nov 7, 2019 at 11:15 AM Cassandra Targett > wrote: >> >> I’m fine with Option 2. >> >> Putting my project manager hat on, I’d really like to see a central list or >> Jira issues of the things we want to make sure to do before we can turn off >> Ant. The list/sub-tasks could be compiled after it’s merged to master, but >> it would be nice if we could approach this in a coordinated way so we’re all >> able to figure out quickly what remains - I think we’ll have a higher chance >> of faster success that way. Hopefully also people would sign up for the >> things that they will volunteer to drive to completion instead of hanging >> back because they aren’t sure what needs to be done. >> >> Dawid and I worked on the Ref Guide transition to Gradle in a separate >> branch and it’s either finished or very close to it IMO. It includes the PR >> I put up last night to remove the PDF build tasks. I just need to merge it >> into the main Gradle branch (jira/SOLR-13452_gradle_8), which I will try to >> do by tomorrow. >> >> Cassandra >> On Nov 6, 2019, 3:07 PM -0600, David Smiley , >> wrote: >> >> Option 2. >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson >> wrote: >>> >>> All: >>> >>> re: SOLR-13452. I’m now coming down on both sides of the issue. My motive >>> here is if this was pushed, even in its current incomplete state, people >>> would have an easier time contributing to the effort. Of course this means >>> I would be asking people to use the gradle build at least on master if at >>> all possible. >>> >>> There are several assumptions I’m making here: >>> >>> - we can keep running the Ant build as long as necessary. Ant would be our >>> primary build process. The purpose of pushing the current Gradle effort is >>> to make it easier for others to contribute and “just try it”. >>> >>> - There are no conflicts between the Gradle and Ant builds, so we can >>> continue to use Ant as necessary until we make the switch. >>> >>> - people will commit up front to putting some effort into this. I flat >>> guarantee I won’t carry the load alone. If nobody else steps up, I’ll table >>> it. I will volunteer to push fixes from non-committers. >>> — Yes, people can do this already with the gradle_8 branch, it’d just be >>> easier if it was already in the pull. >>> >>> - moving to Gradle as our primary workflow won’t happen until we work out >>> some of the kinks, things like. >>> — running on Jenkins. >>> — Getting the equivalent of “ant server dist” to run. >>> — Getting the ref guide built. >>> — I’m sure other things will crop up. >>> >>> >>> So there are several options, please let me know which one you prefer: >>> >>> 1. do nothing. People can check out the gradle_8 build and work on it. >>> There has been some of this so far, many thanks. >>> >>> 2. merge it into master only. TBD is when we take Ant out of master. >>> >>> 3. merge into both master and 8x. Assuming we can continue to use both, I’m >>> not sure what advantage there is to merging into 8x. This seems like >>> something that should come along with a major version release. >>> >>> 4. wait until it’s feature-complete. Based on the evidence so far, this may >>> be a long time coming. >>> >>> Also, the timing is fungible. I don’t see a downside as long as we can >>> continue to build with Ant. I certainly _do_ see a downside if we have to >>> do everything Ant does immediately after pushing to whatever branches. >>> >>> Erick >>> >>> >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> > > > -- > Adrien > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build
I'd be fine with option 2 but I have a slight preference for option 3. If we see the Gradle build as the future default build, then we need to start using it and I wonder that having to use a different workflow on branch_8x would be an incentive to keep using the Ant build instead. On Thu, Nov 7, 2019 at 11:15 AM Cassandra Targett wrote: > > I’m fine with Option 2. > > Putting my project manager hat on, I’d really like to see a central list or > Jira issues of the things we want to make sure to do before we can turn off > Ant. The list/sub-tasks could be compiled after it’s merged to master, but it > would be nice if we could approach this in a coordinated way so we’re all > able to figure out quickly what remains - I think we’ll have a higher chance > of faster success that way. Hopefully also people would sign up for the > things that they will volunteer to drive to completion instead of hanging > back because they aren’t sure what needs to be done. > > Dawid and I worked on the Ref Guide transition to Gradle in a separate branch > and it’s either finished or very close to it IMO. It includes the PR I put up > last night to remove the PDF build tasks. I just need to merge it into the > main Gradle branch (jira/SOLR-13452_gradle_8), which I will try to do by > tomorrow. > > Cassandra > On Nov 6, 2019, 3:07 PM -0600, David Smiley , wrote: > > Option 2. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson > wrote: >> >> All: >> >> re: SOLR-13452. I’m now coming down on both sides of the issue. My motive >> here is if this was pushed, even in its current incomplete state, people >> would have an easier time contributing to the effort. Of course this means I >> would be asking people to use the gradle build at least on master if at all >> possible. >> >> There are several assumptions I’m making here: >> >> - we can keep running the Ant build as long as necessary. Ant would be our >> primary build process. The purpose of pushing the current Gradle effort is >> to make it easier for others to contribute and “just try it”. >> >> - There are no conflicts between the Gradle and Ant builds, so we can >> continue to use Ant as necessary until we make the switch. >> >> - people will commit up front to putting some effort into this. I flat >> guarantee I won’t carry the load alone. If nobody else steps up, I’ll table >> it. I will volunteer to push fixes from non-committers. >> — Yes, people can do this already with the gradle_8 branch, it’d just be >> easier if it was already in the pull. >> >> - moving to Gradle as our primary workflow won’t happen until we work out >> some of the kinks, things like. >> — running on Jenkins. >> — Getting the equivalent of “ant server dist” to run. >> — Getting the ref guide built. >> — I’m sure other things will crop up. >> >> >> So there are several options, please let me know which one you prefer: >> >> 1. do nothing. People can check out the gradle_8 build and work on it. There >> has been some of this so far, many thanks. >> >> 2. merge it into master only. TBD is when we take Ant out of master. >> >> 3. merge into both master and 8x. Assuming we can continue to use both, I’m >> not sure what advantage there is to merging into 8x. This seems like >> something that should come along with a major version release. >> >> 4. wait until it’s feature-complete. Based on the evidence so far, this may >> be a long time coming. >> >> Also, the timing is fungible. I don’t see a downside as long as we can >> continue to build with Ant. I certainly _do_ see a downside if we have to do >> everything Ant does immediately after pushing to whatever branches. >> >> Erick >> >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build
I’m fine with Option 2. Putting my project manager hat on, I’d really like to see a central list or Jira issues of the things we want to make sure to do before we can turn off Ant. The list/sub-tasks could be compiled after it’s merged to master, but it would be nice if we could approach this in a coordinated way so we’re all able to figure out quickly what remains - I think we’ll have a higher chance of faster success that way. Hopefully also people would sign up for the things that they will volunteer to drive to completion instead of hanging back because they aren’t sure what needs to be done. Dawid and I worked on the Ref Guide transition to Gradle in a separate branch and it’s either finished or very close to it IMO. It includes the PR I put up last night to remove the PDF build tasks. I just need to merge it into the main Gradle branch (jira/SOLR-13452_gradle_8), which I will try to do by tomorrow. Cassandra On Nov 6, 2019, 3:07 PM -0600, David Smiley , wrote: > Option 2. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > > On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson > > wrote: > > > All: > > > > > > re: SOLR-13452. I’m now coming down on both sides of the issue. My motive > > > here is if this was pushed, even in its current incomplete state, people > > > would have an easier time contributing to the effort. Of course this > > > means I would be asking people to use the gradle build at least on master > > > if at all possible. > > > > > > There are several assumptions I’m making here: > > > > > > - we can keep running the Ant build as long as necessary. Ant would be > > > our primary build process. The purpose of pushing the current Gradle > > > effort is to make it easier for others to contribute and “just try it”. > > > > > > - There are no conflicts between the Gradle and Ant builds, so we can > > > continue to use Ant as necessary until we make the switch. > > > > > > - people will commit up front to putting some effort into this. I flat > > > guarantee I won’t carry the load alone. If nobody else steps up, I’ll > > > table it. I will volunteer to push fixes from non-committers. > > > — Yes, people can do this already with the gradle_8 branch, it’d just be > > > easier if it was already in the pull. > > > > > > - moving to Gradle as our primary workflow won’t happen until we work out > > > some of the kinks, things like. > > > — running on Jenkins. > > > — Getting the equivalent of “ant server dist” to run. > > > — Getting the ref guide built. > > > — I’m sure other things will crop up. > > > > > > > > > So there are several options, please let me know which one you prefer: > > > > > > 1. do nothing. People can check out the gradle_8 build and work on it. > > > There has been some of this so far, many thanks. > > > > > > 2. merge it into master only. TBD is when we take Ant out of master. > > > > > > 3. merge into both master and 8x. Assuming we can continue to use both, > > > I’m not sure what advantage there is to merging into 8x. This seems like > > > something that should come along with a major version release. > > > > > > 4. wait until it’s feature-complete. Based on the evidence so far, this > > > may be a long time coming. > > > > > > Also, the timing is fungible. I don’t see a downside as long as we can > > > continue to build with Ant. I certainly _do_ see a downside if we have to > > > do everything Ant does immediately after pushing to whatever branches. > > > > > > Erick > > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > > For additional commands, e-mail: dev-h...@lucene.apache.org > > >
Re: Gradle build
Option 2. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson wrote: > All: > > re: SOLR-13452. I’m now coming down on both sides of the issue. My motive > here is if this was pushed, even in its current incomplete state, people > would have an easier time contributing to the effort. Of course this means > I would be asking people to use the gradle build at least on master if at > all possible. > > There are several assumptions I’m making here: > > - we can keep running the Ant build as long as necessary. Ant would be our > primary build process. The purpose of pushing the current Gradle effort is > to make it easier for others to contribute and “just try it”. > > - There are no conflicts between the Gradle and Ant builds, so we can > continue to use Ant as necessary until we make the switch. > > - people will commit up front to putting some effort into this. I flat > guarantee I won’t carry the load alone. If nobody else steps up, I’ll table > it. I will volunteer to push fixes from non-committers. > — Yes, people can do this already with the gradle_8 branch, it’d just be > easier if it was already in the pull. > > - moving to Gradle as our primary workflow won’t happen until we work out > some of the kinks, things like. > — running on Jenkins. > — Getting the equivalent of “ant server dist” to run. > — Getting the ref guide built. > — I’m sure other things will crop up. > > > So there are several options, please let me know which one you prefer: > > 1. do nothing. People can check out the gradle_8 build and work on it. > There has been some of this so far, many thanks. > > 2. merge it into master only. TBD is when we take Ant out of master. > > 3. merge into both master and 8x. Assuming we can continue to use both, > I’m not sure what advantage there is to merging into 8x. This seems like > something that should come along with a major version release. > > 4. wait until it’s feature-complete. Based on the evidence so far, this > may be a long time coming. > > Also, the timing is fungible. I don’t see a downside as long as we can > continue to build with Ant. I certainly _do_ see a downside if we have to > do everything Ant does immediately after pushing to whatever branches. > > Erick > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Gradle build
> — Getting the equivalent of “ant server dist” to run. I never managed to understand what the proper assembly workflow is in Solr, to be honest... the "create-package", "dist-*", "package-*" tasks -- do all of these make sense (and need to be exposed in gradle)? > — Getting the ref guide built. This should be done on a branch already. > — I’m sure other things will crop up. Oh, I'm sure they will ;) D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Gradle build
+1 to option 2. As I'm working on the package manager, I hope to move to splitting up pieces of Solr into their own packages (so as to have a lean core). Having the gradle build will be important at that time, so I have keen interest in seeing it merged soon. On Wed, Nov 6, 2019 at 11:06 PM Erick Erickson wrote: > > All: > > re: SOLR-13452. I’m now coming down on both sides of the issue. My motive > here is if this was pushed, even in its current incomplete state, people > would have an easier time contributing to the effort. Of course this means I > would be asking people to use the gradle build at least on master if at all > possible. > > There are several assumptions I’m making here: > > - we can keep running the Ant build as long as necessary. Ant would be our > primary build process. The purpose of pushing the current Gradle effort is to > make it easier for others to contribute and “just try it”. > > - There are no conflicts between the Gradle and Ant builds, so we can > continue to use Ant as necessary until we make the switch. > > - people will commit up front to putting some effort into this. I flat > guarantee I won’t carry the load alone. If nobody else steps up, I’ll table > it. I will volunteer to push fixes from non-committers. > — Yes, people can do this already with the gradle_8 branch, it’d just be > easier if it was already in the pull. > > - moving to Gradle as our primary workflow won’t happen until we work out > some of the kinks, things like. > — running on Jenkins. > — Getting the equivalent of “ant server dist” to run. > — Getting the ref guide built. > — I’m sure other things will crop up. > > > So there are several options, please let me know which one you prefer: > > 1. do nothing. People can check out the gradle_8 build and work on it. There > has been some of this so far, many thanks. > > 2. merge it into master only. TBD is when we take Ant out of master. > > 3. merge into both master and 8x. Assuming we can continue to use both, I’m > not sure what advantage there is to merging into 8x. This seems like > something that should come along with a major version release. > > 4. wait until it’s feature-complete. Based on the evidence so far, this may > be a long time coming. > > Also, the timing is fungible. I don’t see a downside as long as we can > continue to build with Ant. I certainly _do_ see a downside if we have to do > everything Ant does immediately after pushing to whatever branches. > > Erick > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
