Re: Anyone interested in the Gradle build, please comment on SOLR-13915
I can handle this, Erick (on the branch). In short, "assemble" is a task added by the "base" gradle plugin. This is just a placeholder for things that should be "assembled" in the project. The java plugin puts together a jar file from compiled classes, for example. Gradle projects typically don't collect dependency jars anywhere (they suck them in from caches without copying whenever they're needed). We can copy them over though -- this is simple. D. On Sat, Nov 16, 2019 at 3:44 AM Erick Erickson wrote: > > In a nutshell, it doesn’t look like there’s any task that populates: > > ../solr/server/solr-webapp/webapp/WEB-INF/lib/ > ../solr/server/lib/ext/ > ../solr/server/lib/ > > with jar files. So "solr/bin/solr start” simply can’t start since it defines > CLASSPATH to point to them. Before I try to mimic the Ant build that > populates these, should we re-think how these are populated and/or where they > live? > > “gradlew assemble” pulls the jars down, but I sure can’t find anywhere where > that task is defined, and the Gradle javadocs say things like: > > assemble() - Method in class org.gradle.language.assembler.tasks.Assemble > > Assemble - Class in org.gradle.language.assembler.tasks > Translates Assembly language source files into object files. > > so I haven’t a clue what’s up with that task. > > Thanks, > 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
Re: gradle module/project structure
Thanks, I just put it in gradle tasks for now. on to the equivalent of “ant server dist”. > On Nov 15, 2019, at 1:03 PM, Dawid Weiss wrote: > > Doesn't make sense to spend much time on such discussions, Erick, not > at this early stage. If you like it -- leave it in, I have no problem > with it whatsoever. > > Dawid > > On Fri, Nov 15, 2019 at 6:02 PM Erick Erickson > wrote: >> >> Added SOLR-13935 for this general topic, please comment there if you’d >> rather. >> >>> On Nov 15, 2019, at 10:36 AM, Dawid Weiss wrote: >>> Instead of a help.txt file though, how about some help task? ./gradlew helpAnt? >>> >>> I don't think that's easier, to be honest. You need to know which task >>> to invoke (and how). >>> A plain file is just right there in your face. >>> it works just fine. Does this seem consistent with the structure of the Gradle build? >>> >>> There is no one "structure" to a gradle build. There are some >>> conventions but they're much more relaxed compared to Maven (or even >>> ant). A gradle build is really just an arrangement of code blobs... >>> how you write it is up to you. >>> >>> "../solr_gradle_8/help/build.gradle” to have a “help” prefix. >>> helpTest, helpAnt, helpBuild (and, BTW, I really like that tasks >>> aren’t case-sensitive). >>> >>> I personally don't like the fact you need to run gradle to display a >>> text file... Mark added it at the beginning but I don't think it's >>> really necessary. If you've done it already, so be it. >>> Here’s the diff, FYI. If this looks like it doesn’t do violence to the structure of the gradle build I’ll check it in. >>> >>> It's fine I think. But again -- why pollute the build file with stuff >>> that could be just a set of plain-text files (which people can display >>> with anything they like)? Occam's razor -- the simplest method is >>> typically the best. >>> >>> D. >>> >>> - >>> 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 > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Anyone interested in the Gradle build, please comment on SOLR-13915
In a nutshell, it doesn’t look like there’s any task that populates: ../solr/server/solr-webapp/webapp/WEB-INF/lib/ ../solr/server/lib/ext/ ../solr/server/lib/ with jar files. So "solr/bin/solr start” simply can’t start since it defines CLASSPATH to point to them. Before I try to mimic the Ant build that populates these, should we re-think how these are populated and/or where they live? “gradlew assemble” pulls the jars down, but I sure can’t find anywhere where that task is defined, and the Gradle javadocs say things like: assemble() - Method in class org.gradle.language.assembler.tasks.Assemble Assemble - Class in org.gradle.language.assembler.tasks Translates Assembly language source files into object files. so I haven’t a clue what’s up with that task. Thanks, Erick - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Houston Putman as Lucene/Solr committer
Welcome, Houston! On Fri, Nov 15, 2019 at 6:00 PM Shalin Shekhar Mangar < shalinman...@gmail.com> wrote: > Congratulations and welcome Houston! > > On Thu, Nov 14, 2019 at 12:39 PM Houston Putman > wrote: > >> Thanks everyone! >> >> As requested, a brief history of me: >> >> A native Austinite, I went to The University of Texas at Austin. Back in >> 2013 I lucked into an internship with Bloomberg working on a new Search >> Infrastructure team. There I had my first exposure to Solr and built the >> first iteration of the Analytics Component. Since graduating in 2016, >> moving up to NYC and starting at Bloomberg full time, I have been working >> on Solr in various ways, from rewriting the Analytics Component to adding >> some features to various parts of SolrJ and fixing some weirdness in pivot >> facets. >> >> Lately I’ve been working (and presenting) on running Solr on Kubernetes. >> We’ve open sourced a Solr Kubernetes operator ( >> https://github.com/bloomberg/solr-operator), which is currently being >> developed with help from across the community. Our goal is to make this a >> standard and flexible way of running Solr in a cloud environment, which >> includes making Solr itself run better in the cloud. >> >> I can’t wait to continue working with y’all and making Solr as great as >> it can be! >> >> >> - Houston Putman >> >> On Thu, Nov 14, 2019 at 2:24 PM Varun Thacker wrote: >> >>> Congratulations and welcome Houston! >>> >>> On Thu, Nov 14, 2019 at 9:32 AM Tomás Fernández Löbbe < >>> tomasflo...@gmail.com> wrote: >>> Welcome Houston! On Thu, Nov 14, 2019 at 9:09 AM Kevin Risden wrote: > Congrats and welcome! > > Kevin Risden > > On Thu, Nov 14, 2019, 12:05 Jason Gerlowski > wrote: > >> Congratulations! >> >> On Thu, Nov 14, 2019 at 11:58 AM Gus Heck wrote: >> > >> > Congratulations and welcome :) >> > >> > On Thu, Nov 14, 2019 at 11:52 AM Namgyu Kim >> wrote: >> >> >> >> Congratulations and welcome, Houston! :D >> >> >> >> On Fri, Nov 15, 2019 at 1:18 AM Ken LaPorte >> wrote: >> >>> >> >>> Congratulations Houston! Well deserved honor. >> >>> >> >>> >> >>> >> >>> -- >> >>> Sent from: >> https://lucene.472066.n3.nabble.com/Lucene-Java-Developer-f564358.html >> >>> >> >>> >> - >> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >>> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>> >> > >> > >> > -- >> > http://www.needhamsoftware.com (work) >> > http://www.the111shift.com (play) >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > > -- > Regards, > Shalin Shekhar Mangar. >
Re: Welcome Houston Putman as Lucene/Solr committer
Congratulations and welcome Houston! On Thu, Nov 14, 2019 at 12:39 PM Houston Putman wrote: > Thanks everyone! > > As requested, a brief history of me: > > A native Austinite, I went to The University of Texas at Austin. Back in > 2013 I lucked into an internship with Bloomberg working on a new Search > Infrastructure team. There I had my first exposure to Solr and built the > first iteration of the Analytics Component. Since graduating in 2016, > moving up to NYC and starting at Bloomberg full time, I have been working > on Solr in various ways, from rewriting the Analytics Component to adding > some features to various parts of SolrJ and fixing some weirdness in pivot > facets. > > Lately I’ve been working (and presenting) on running Solr on Kubernetes. > We’ve open sourced a Solr Kubernetes operator ( > https://github.com/bloomberg/solr-operator), which is currently being > developed with help from across the community. Our goal is to make this a > standard and flexible way of running Solr in a cloud environment, which > includes making Solr itself run better in the cloud. > > I can’t wait to continue working with y’all and making Solr as great as it > can be! > > > - Houston Putman > > On Thu, Nov 14, 2019 at 2:24 PM Varun Thacker wrote: > >> Congratulations and welcome Houston! >> >> On Thu, Nov 14, 2019 at 9:32 AM Tomás Fernández Löbbe < >> tomasflo...@gmail.com> wrote: >> >>> Welcome Houston! >>> >>> On Thu, Nov 14, 2019 at 9:09 AM Kevin Risden wrote: >>> Congrats and welcome! Kevin Risden On Thu, Nov 14, 2019, 12:05 Jason Gerlowski wrote: > Congratulations! > > On Thu, Nov 14, 2019 at 11:58 AM Gus Heck wrote: > > > > Congratulations and welcome :) > > > > On Thu, Nov 14, 2019 at 11:52 AM Namgyu Kim > wrote: > >> > >> Congratulations and welcome, Houston! :D > >> > >> On Fri, Nov 15, 2019 at 1:18 AM Ken LaPorte > wrote: > >>> > >>> Congratulations Houston! Well deserved honor. > >>> > >>> > >>> > >>> -- > >>> Sent from: > https://lucene.472066.n3.nabble.com/Lucene-Java-Developer-f564358.html > >>> > >>> > - > >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >>> For additional commands, e-mail: dev-h...@lucene.apache.org > >>> > > > > > > -- > > http://www.needhamsoftware.com (work) > > http://www.the111shift.com (play) > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Regards, Shalin Shekhar Mangar.
Re: Do we want to pursue an LTS designation?
Bram: Andrzej Bailecki and I worked on something similar, it might be good to compare notes. I gave a talk last Activate that might be useful for you to look at for ideas. Basically there are several issues we worked out: 1> how to insure that all segments were rewritten 2> If the schema is changing, how to update the collections one at a time even with shared configsets 3> the nuts-and-bolts of the rewriting. https://www.youtube.com/watch?v=eaQBH_H3d3g Best, Erick > On Nov 15, 2019, at 2:15 PM, Bram Van Dam wrote: > > On 15/11/2019 19:14, Jörn Franke wrote: >> Well sometimes even reindexing might not always be avoidable when upgrading. >> However, there should be a more user friendly way. Not every Solr deployment >> that one might inherit has foreseen this. Eg in case Solr is used as a NoSQL >> database where the application puts data in Solr, but not outside Solr for >> the case of reindexing. In those case it would be useful that Solr can >> (configurable) write the original SolrInputDocument somewhere and this >> original document can then be user for reindexing in case of major updates. > > Writing the SolrInputDocument to disk would get really expensive really > quickly. > > When all fields are stored it's relatively easy to build a new index > from an old one. But when you have a any non-stored fields, things > become a bit less convenient. In some cases you can uninvert the field > and recreate the content based on the terms used. Still tricky. > > A way to perform in-place updates in Lucene would help in this case. But > that seems hard to implement, and it would only help with this > particular upgrade problem. > > When I have more time I'll keep hacking away on an upgrade tool that > works for our use-case. If it turns out to be usable for anyone else, > I'll give it back to the community. > > Also; not sure why the MS mail servers are messing up some of my mails. > Apologies. > > - Bram > > - > 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: Do we want to pursue an LTS designation?
On 15/11/2019 19:14, Jörn Franke wrote: > Well sometimes even reindexing might not always be avoidable when upgrading. > However, there should be a more user friendly way. Not every Solr deployment > that one might inherit has foreseen this. Eg in case Solr is used as a NoSQL > database where the application puts data in Solr, but not outside Solr for > the case of reindexing. In those case it would be useful that Solr can > (configurable) write the original SolrInputDocument somewhere and this > original document can then be user for reindexing in case of major updates. Writing the SolrInputDocument to disk would get really expensive really quickly. When all fields are stored it's relatively easy to build a new index from an old one. But when you have a any non-stored fields, things become a bit less convenient. In some cases you can uninvert the field and recreate the content based on the terms used. Still tricky. A way to perform in-place updates in Lucene would help in this case. But that seems hard to implement, and it would only help with this particular upgrade problem. When I have more time I'll keep hacking away on an upgrade tool that works for our use-case. If it turns out to be usable for anyone else, I'll give it back to the community. Also; not sure why the MS mail servers are messing up some of my mails. Apologies. - Bram
Re: Do we want to pursue an LTS designation?
Well sometimes even reindexing might not always be avoidable when upgrading. However, there should be a more user friendly way. Not every Solr deployment that one might inherit has foreseen this. Eg in case Solr is used as a NoSQL database where the application puts data in Solr, but not outside Solr for the case of reindexing. In those case it would be useful that Solr can (configurable) write the original SolrInputDocument somewhere and this original document can then be user for reindexing in case of major updates. > Am 15.11.2019 um 18:50 schrieb Bram Van Dam : > > On 13/11/2019 20:36, Erick Erickson wrote: >> I have zero interest in having an LTS “policy†that requires any further >> commitment of my personal time to random people who ask for it but aren’t >> willing to pay. I consider my non-paid work to Solr a _volunteer_ activity, >> not something anyone has a right to demand as “supportâ€, long-term or >> otherwise. > > I hope no one is expecting you to put in free support hours based on > some random LTS designation. And if you're ever in my neck of the woods, > I'll gladly buy you a couple of beers to thank you for the effort you do > put in. > > It *is* really annoying that there is no better upgrade path than > "reindex everything and hope for the best". Making it easier to perform > in place upgrades would probably go a long way in making users happier, > and would certainly reduce the calls for an LTS version. > > I had some time off this week and I spent it poking around at the > possibility of making index upgrades easier, but I'm afraid I didn't get > anywhere with it. Too much low level Lucene stuff is involved that I'm > not familiar with (yet). > > - Bram > B‹CB•È [œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™P XÙ[™K˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[ˆ]‹Z[ XÙ[™K˜\XÚK›Ü™ÃBƒB - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Do we want to pursue an LTS designation?
Well sometimes even reindexing might not always be avoidable when upgrading. However, there should be a more user friendly way. Not every Solr deployment that one might inherit has foreseen this. Eg in case Solr is used as a NoSQL database where the application puts data in Solr, but not outside Solr for the case of reindexing. In those case it would be useful that Solr can (configurable) write the original SolrInputDocument somewhere and this original document can then be user for reindexing in case of major updates. > Am 15.11.2019 um 18:50 schrieb Bram Van Dam : > > On 13/11/2019 20:36, Erick Erickson wrote: >> I have zero interest in having an LTS “policy†that requires any further >> commitment of my personal time to random people who ask for it but aren’t >> willing to pay. I consider my non-paid work to Solr a _volunteer_ activity, >> not something anyone has a right to demand as “supportâ€, long-term or >> otherwise. > > I hope no one is expecting you to put in free support hours based on > some random LTS designation. And if you're ever in my neck of the woods, > I'll gladly buy you a couple of beers to thank you for the effort you do > put in. > > It *is* really annoying that there is no better upgrade path than > "reindex everything and hope for the best". Making it easier to perform > in place upgrades would probably go a long way in making users happier, > and would certainly reduce the calls for an LTS version. > > I had some time off this week and I spent it poking around at the > possibility of making index upgrades easier, but I'm afraid I didn't get > anywhere with it. Too much low level Lucene stuff is involved that I'm > not familiar with (yet). > > - Bram > B‹CB•È [œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™P XÙ[™K˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[ˆ]‹Z[ XÙ[™K˜\XÚK›Ü™ÃBƒB - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: gradle module/project structure
Doesn't make sense to spend much time on such discussions, Erick, not at this early stage. If you like it -- leave it in, I have no problem with it whatsoever. Dawid On Fri, Nov 15, 2019 at 6:02 PM Erick Erickson wrote: > > Added SOLR-13935 for this general topic, please comment there if you’d rather. > > > On Nov 15, 2019, at 10:36 AM, Dawid Weiss wrote: > > > >> Instead of a help.txt file though, how about some help task? ./gradlew > >> helpAnt? > > > > I don't think that's easier, to be honest. You need to know which task > > to invoke (and how). > > A plain file is just right there in your face. > > > >> it works just fine. Does this seem consistent with the structure of the > >> Gradle build? > > > > There is no one "structure" to a gradle build. There are some > > conventions but they're much more relaxed compared to Maven (or even > > ant). A gradle build is really just an arrangement of code blobs... > > how you write it is up to you. > > > > "../solr_gradle_8/help/build.gradle” to have a “help” prefix. > > helpTest, helpAnt, helpBuild (and, BTW, I really like that tasks > > aren’t case-sensitive). > > > > I personally don't like the fact you need to run gradle to display a > > text file... Mark added it at the beginning but I don't think it's > > really necessary. If you've done it already, so be it. > > > >> Here’s the diff, FYI. If this looks like it doesn’t do violence to the > >> structure of the gradle build I’ll check it in. > > > > It's fine I think. But again -- why pollute the build file with stuff > > that could be just a set of plain-text files (which people can display > > with anything they like)? Occam's razor -- the simplest method is > > typically the best. > > > > D. > > > > - > > 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: Do we want to pursue an LTS designation?
On 13/11/2019 20:36, Erick Erickson wrote: > I have zero interest in having an LTS “policy” that requires any further > commitment of my personal time to random people who ask for it but aren’t > willing to pay. I consider my non-paid work to Solr a _volunteer_ activity, > not something anyone has a right to demand as “support”, long-term or > otherwise. I hope no one is expecting you to put in free support hours based on some random LTS designation. And if you're ever in my neck of the woods, I'll gladly buy you a couple of beers to thank you for the effort you do put in. It *is* really annoying that there is no better upgrade path than "reindex everything and hope for the best". Making it easier to perform in place upgrades would probably go a long way in making users happier, and would certainly reduce the calls for an LTS version. I had some time off this week and I spent it poking around at the possibility of making index upgrades easier, but I'm afraid I didn't get anywhere with it. Too much low level Lucene stuff is involved that I'm not familiar with (yet). - Bram
Re: gradle module/project structure
Added SOLR-13935 for this general topic, please comment there if you’d rather. > On Nov 15, 2019, at 10:36 AM, Dawid Weiss wrote: > >> Instead of a help.txt file though, how about some help task? ./gradlew >> helpAnt? > > I don't think that's easier, to be honest. You need to know which task > to invoke (and how). > A plain file is just right there in your face. > >> it works just fine. Does this seem consistent with the structure of the >> Gradle build? > > There is no one "structure" to a gradle build. There are some > conventions but they're much more relaxed compared to Maven (or even > ant). A gradle build is really just an arrangement of code blobs... > how you write it is up to you. > > "../solr_gradle_8/help/build.gradle” to have a “help” prefix. > helpTest, helpAnt, helpBuild (and, BTW, I really like that tasks > aren’t case-sensitive). > > I personally don't like the fact you need to run gradle to display a > text file... Mark added it at the beginning but I don't think it's > really necessary. If you've done it already, so be it. > >> Here’s the diff, FYI. If this looks like it doesn’t do violence to the >> structure of the gradle build I’ll check it in. > > It's fine I think. But again -- why pollute the build file with stuff > that could be just a set of plain-text files (which people can display > with anything they like)? Occam's razor -- the simplest method is > typically the best. > > D. > > - > 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 module/project structure
> But again -- why pollute the build file with stuff > that could be just a set of plain-text files All depends on how you define “simplest" ;). One definition is how few different systems I have to use. Another is how can I get this information in the least complicated way I don’t have a lot of skin in this game, AFAIC let’s just pick one way and go about it. What do people think? 1> have the bits in Gradle that print the different help files as now. 1a> in this case, add a plain-text file at the root directing people who like editors to help/help-text…. 2> have a simple Gradle help task that tells people to look in help/help-text for the plain text versions. I like 1 best on the principle that it’s one less place people need to know about to look. BTW, part of the output of "gradlew tasks” Help (Build Documentation) tasks helpAnt - Ant equivalences in the Gradle build. helpBuild - Information on using Docker to test that your build changes are not too disruptive. helpDeps - How dependencies are managed and what you need to know to change them. helpTest - How to run Lucene and Solr tests and the options that are available to you. which is actually kind of nice. Let me know. > On Nov 15, 2019, at 10:36 AM, Dawid Weiss wrote: > >> Instead of a help.txt file though, how about some help task? ./gradlew >> helpAnt? > > I don't think that's easier, to be honest. You need to know which task > to invoke (and how). > A plain file is just right there in your face. > >> it works just fine. Does this seem consistent with the structure of the >> Gradle build? > > There is no one "structure" to a gradle build. There are some > conventions but they're much more relaxed compared to Maven (or even > ant). A gradle build is really just an arrangement of code blobs... > how you write it is up to you. > > "../solr_gradle_8/help/build.gradle” to have a “help” prefix. > helpTest, helpAnt, helpBuild (and, BTW, I really like that tasks > aren’t case-sensitive). > > I personally don't like the fact you need to run gradle to display a > text file... Mark added it at the beginning but I don't think it's > really necessary. If you've done it already, so be it. > >> Here’s the diff, FYI. If this looks like it doesn’t do violence to the >> structure of the gradle build I’ll check it in. > > It's fine I think. But again -- why pollute the build file with stuff > that could be just a set of plain-text files (which people can display > with anything they like)? Occam's razor -- the simplest method is > typically the best. > > D. > > - > 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: Welcome Houston Putman as Lucene/Solr committer
Congrats and welcome Houston! -- Steve > On Nov 15, 2019, at 1:09 AM, Houston Putman wrote: > > Thanks everyone! > > As requested, a brief history of me: > > A native Austinite, I went to The University of Texas at Austin. Back in 2013 > I lucked into an internship with Bloomberg working on a new Search > Infrastructure team. There I had my first exposure to Solr and built the > first iteration of the Analytics Component. Since graduating in 2016, moving > up to NYC and starting at Bloomberg full time, I have been working on Solr in > various ways, from rewriting the Analytics Component to adding some features > to various parts of SolrJ and fixing some weirdness in pivot facets. > > Lately I’ve been working (and presenting) on running Solr on Kubernetes. > We’ve open sourced a Solr Kubernetes operator > (https://github.com/bloomberg/solr-operator), which is currently being > developed with help from across the community. Our goal is to make this a > standard and flexible way of running Solr in a cloud environment, which > includes making Solr itself run better in the cloud. > > I can’t wait to continue working with y’all and making Solr as great as it > can be! > > - Houston Putman > > On Thu, Nov 14, 2019 at 2:24 PM Varun Thacker wrote: > Congratulations and welcome Houston! > > On Thu, Nov 14, 2019 at 9:32 AM Tomás Fernández Löbbe > wrote: > Welcome Houston! > > On Thu, Nov 14, 2019 at 9:09 AM Kevin Risden wrote: > Congrats and welcome! > > Kevin Risden > > On Thu, Nov 14, 2019, 12:05 Jason Gerlowski wrote: > Congratulations! > > On Thu, Nov 14, 2019 at 11:58 AM Gus Heck wrote: > > > > Congratulations and welcome :) > > > > On Thu, Nov 14, 2019 at 11:52 AM Namgyu Kim wrote: > >> > >> Congratulations and welcome, Houston! :D > >> > >> On Fri, Nov 15, 2019 at 1:18 AM Ken LaPorte wrote: > >>> > >>> Congratulations Houston! Well deserved honor. > >>> > >>> > >>> > >>> -- > >>> Sent from: > >>> https://lucene.472066.n3.nabble.com/Lucene-Java-Developer-f564358.html > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >>> For additional commands, e-mail: dev-h...@lucene.apache.org > >>> > > > > > > -- > > http://www.needhamsoftware.com (work) > > http://www.the111shift.com (play) > > - > 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: Welcome Houston Putman as Lucene/Solr committer
Congrats and welcome, Houston! (Austin is a great city, we had the Lucene Solr Revolution there one!) On Fri, Nov 15, 2019 at 9:59 PM Ignacio Vera wrote: > > Welcome Houston! > > On Fri, Nov 15, 2019 at 11:07 AM Alan Woodward wrote: >> >> Welcome Houston! >> >> > On 14 Nov 2019, at 08:57, Anshum Gupta wrote: >> > >> > Hi all, >> > >> > Please join me in welcoming Houston Putman as the latest Lucene/Solr >> > committer! >> > >> > Houston has been involved with the community since 2013, when he first >> > contributed the Analytics contrib module. Since then he has been involved >> > with the community, participated in conferences and spoken about his work >> > with Lucene/Solr. In the recent past, he has been involved with getting >> > Solr to scale on Kubernetes. >> > >> > Looking forward to your commits to the Apache Lucene/Solr project :) >> > >> > Congratulations and welcome, Houston! It's a tradition to introduce >> > yourself with a brief bio. >> > >> > -- >> > Anshum Gupta >> >> >> - >> 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: Welcome Houston Putman as Lucene/Solr committer
Welcome Houston! On Fri, Nov 15, 2019 at 11:07 AM Alan Woodward wrote: > Welcome Houston! > > > On 14 Nov 2019, at 08:57, Anshum Gupta wrote: > > > > Hi all, > > > > Please join me in welcoming Houston Putman as the latest Lucene/Solr > committer! > > > > Houston has been involved with the community since 2013, when he first > contributed the Analytics contrib module. Since then he has been involved > with the community, participated in conferences and spoken about his work > with Lucene/Solr. In the recent past, he has been involved with getting > Solr to scale on Kubernetes. > > > > Looking forward to your commits to the Apache Lucene/Solr project :) > > > > Congratulations and welcome, Houston! It's a tradition to introduce > yourself with a brief bio. > > > > -- > > Anshum Gupta > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: gradle module/project structure
> Instead of a help.txt file though, how about some help task? ./gradlew > helpAnt? I don't think that's easier, to be honest. You need to know which task to invoke (and how). A plain file is just right there in your face. > it works just fine. Does this seem consistent with the structure of the > Gradle build? There is no one "structure" to a gradle build. There are some conventions but they're much more relaxed compared to Maven (or even ant). A gradle build is really just an arrangement of code blobs... how you write it is up to you. "../solr_gradle_8/help/build.gradle” to have a “help” prefix. helpTest, helpAnt, helpBuild (and, BTW, I really like that tasks aren’t case-sensitive). I personally don't like the fact you need to run gradle to display a text file... Mark added it at the beginning but I don't think it's really necessary. If you've done it already, so be it. > Here’s the diff, FYI. If this looks like it doesn’t do violence to the > structure of the gradle build I’ll check it in. It's fine I think. But again -- why pollute the build file with stuff that could be just a set of plain-text files (which people can display with anything they like)? Occam's razor -- the simplest method is typically the best. D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: gradle module/project structure
Ohhh, I really like this, especially given the amount of time I’ve spent
looking at all of the possible tasks….
Instead of a help.txt file though, how about some help task? ./gradlew helpAnt?
But I need a sanity check here before pushing this (assuming y’all agree)
before I go changing some things:
“./gradlew tests” (note the plural) fails with:
java.io.FileNotFoundException:
/Users/Erick/apache/solrVersions/solr-gradle_8/buildSrc/common/help-text/testHelp.txt
(No such file or directory)
And, indeed, there is no such file. However, there is a file:
/Users/Erick/apache/solrVersions/solr-gradle_8/help/help-text/testHelp.txt
So if I change the file: ../solr_gradle_8/help/build.gradle (the “tests” task)
from:
println file("${rootDir}/buildSrc/common/help-text/testHelp.txt").text
to
println file("${rootDir}/help/help-text/testHelp.txt").text
it works just fine. Does this seem consistent with the structure of the Gradle
build? I don’t want to blunder about with things like this without checking
what others think until I get a better feel for how this all should work.
A couple of other things:
1> I detest a “test” and “tests” tasks having wildly different outcomes, so I
changed all the tasks in "../solr_gradle_8/help/build.gradle” to have a “help”
prefix. helpTest, helpAnt, helpBuild (and, BTW, I really like that tasks aren’t
case-sensitive).
2> I added a new file "../solr_gradle_8/help/help-text/antHelp.txt” to be the
printout of a new task “helpAnt” that has Dawid’s suggestions in it.
And there’s an empty file: .../solr-gradle_8/buildSrc/common/build-help.gradle.
It’s unclear to me what the intention is here, but from what I can see it’s a
stub for building
Here’s the diff, FYI. If this looks like it doesn’t do violence to the
structure of the gradle build I’ll check it in.
diff --git a/help/build.gradle b/help/build.gradle
index 2918118ab93..5504cdf679e 100644
--- a/help/build.gradle
+++ b/help/build.gradle
@@ -22,15 +22,25 @@ sourceSets {
}
}
-task tests {
+task helpTest {
group = 'Help (Build Documentation)'
description = "How to run Lucene and Solr tests and the options that are
available to you."
doLast {
-println file("${rootDir}/buildSrc/common/help-text/testHelp.txt").text
+println file("${rootDir}/help/help-text/testHelp.txt").text
}
}
+task helpAnt {
+ group = 'Help (Build Documentation)'
+ description = "Ant equivalences in the Gradle build."
+
+ doLast {
+println file("${rootDir}/help/help-text/antHelp.txt").text
+ }
+}
+
+
task deps {
group = 'Help (Build Documentation)'
description = "How dependencies are managed and what you need to know to
change them."
@@ -39,7 +49,7 @@ task deps {
}
}
-task testBuild {
+task helpBuild {
group = 'Help (Build Documentation)'
description = "Information on using Docker to test that your build changes
are not too disruptive."
}
> On Nov 15, 2019, at 4:30 AM, Dawid Weiss wrote:
>
> ant compile => gradlew compileJava
> ant jar => gradlew package
> ant clean => gradlew clean
> ant clean-jars => [no replacement - JARs sourced directly from gradle caches]
> ant jar-checksums => gradlew jarChecksums
> ant test => gradlew test [or better (includes any other verification
> tasks): gradlew check]
> ant validate => gradlew check
> ant precommit => TODO
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Houston Putman as Lucene/Solr committer
Welcome Houston! > On 14 Nov 2019, at 08:57, Anshum Gupta wrote: > > Hi all, > > Please join me in welcoming Houston Putman as the latest Lucene/Solr > committer! > > Houston has been involved with the community since 2013, when he first > contributed the Analytics contrib module. Since then he has been involved > with the community, participated in conferences and spoken about his work > with Lucene/Solr. In the recent past, he has been involved with getting Solr > to scale on Kubernetes. > > Looking forward to your commits to the Apache Lucene/Solr project :) > > Congratulations and welcome, Houston! It's a tradition to introduce yourself > with a brief bio. > > -- > Anshum Gupta - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: gradle module/project structure
> Want to raise a JIRA (task?) and put it in the umbrella task? (SOLR-13914)? > I’m trying to keep all these kinds of TODO’s in a place we won’t forget them. I won't forget this -- it's too annoying. ;) We can't change the folder structure now because merges would be too painful (and if we want to keep parallel build systems in place we can't do it anyway). This really is of low priority. What we should have in place is a list of common ant tasks that people use and a corresponding list of gradle commands -- this would ease the transition and encourage people to try the gradle build. I'd create an in-your-face top-level file "help.txt" and have a concise list of these. It can also be prioritized so that we know what needs to be ported asap? I can think of: ant compile => gradlew compileJava ant jar => gradlew package ant clean => gradlew clean ant clean-jars => [no replacement - JARs sourced directly from gradle caches] ant jar-checksums => gradlew jarChecksums ant test => gradlew test [or better (includes any other verification tasks): gradlew check] ant validate => gradlew check ant precommit => TODO If there's anything people regularly use, I'd add it to the list above. Most tasks that are rarely (or never) used I would *not* port from ant. Things like "jar-src" or "jacoco"... They should be components of other higher-level tasks or even subprojects on their own (jacoco could be a "check" task on a submodule called "tests:coverage" for example). A prioritized list of common workflow is really necessary to know which things are needed first so that people can start to use it for work. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
