Re: Cleaning up IntelliJ warnings in code base

[David Smiley]

Here it is.

  
  

  
  
  
  
  


  
  

  
  
  
  
  


  
  
  
  
  


  
  
  
  
  
  

  
  

  

  
  
  
  
  
  
  

  


  
  


  
  
  
  

  
  

  
  

  


  


  


  


  


  


  


  






  
  
  

  
  
  









  
  
  
  

  
  

  
  
  


  
  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  
  





  
  






  
  

  
  

  
  



  
  
  

  
  
  
  
  
  


  
  
  


  
  



  
  
  
  
  
  
  
  
  
  

  
  
  



  
  



  
  




  
  
  



  
  










  

-
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

Re: Cleaning up IntelliJ warnings in code base

[Eric Pugh]

t; <
>> https://www.jetbrains.com/help/idea/code-inspection.html#access-inspections-and-settings
>>  
>> <https://www.jetbrains.com/help/idea/code-inspection.html#access-inspections-and-settings>
>>>> 
>>>> that we can customize.
>>>> 
>>>> It appears that there is a .idea/InspectionProfiles directory that maybe
>>>> our gradle build could somehow tie into…. Run gradlew idea and have
>> our
>>>> inspection file setup for us?
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Aug 18, 2022, at 12:03 AM, Houston Putman >>>> <mailto:hous...@apache.org>>
>> wrote:
>>>>> 
>>>>> I completely understand your concern and frustration for the
>>>>> solrj-zookeeper PR David, it's been in the works for a while, and these
>>>>> refactorings are very hard on you and the contributor you are working
>>>> with.
>>>>> 
>>>>> Eric and I talked, and given that there are very few giant PRs that are
>>>> in
>>>>> progress, we agreed this work can likely continue after the
>>>> solrj-zookeeper
>>>>> PR is merged.
>>>>> 
>>>>> Going forward though, I think the strategy is going to be to attack
>>>>> package-by-package (addressing all issues in that package), instead of
>>>>> intelliJ issue by intelliJ issue (addressing all packages at the same
>>>>> time). That way, the PRs are confined to a specific area, so for
>> example
>>>>> the solrj-zookeeper work would be unaffected unless Eric decided to
>>>> tackle
>>>>> the solrj packages, which he could obviously postpone.
>>>>> 
>>>>> I think we can all agree that the Solr codebase can be a mess, and
>> things
>>>>> are not always done the way that they should be. Projects need
>>>> maintenance
>>>>> in order to survive. I think it's great that Eric is putting in
>>>> tremendous
>>>>> time and effort in order to improve the project in a pretty thankless
>>>> way.
>>>>> 
>>>>> Anyways happy to entertain further discussion on the topic, but I think
>>>> the
>>>>> new strategy is the best compromise of moving forward without making
>>>> things
>>>>> hard for others trying to contribute.
>>>>> 
>>>>> - Houston
>>>>> 
>>>>> On Sat, Jul 30, 2022 at 4:38 PM Ishan Chattopadhyaya <
>>>>> ichattopadhy...@gmail.com <mailto:ichattopadhy...@gmail.com>> wrote:
>>>>> 
>>>>>>> I ask that you please suspend sweeping changes because they are a
>> real
>>>>>> impediment to other branches/PRs that move lots of files.  This is
>>>>>> happening right now: https://github.com/apache/solr/pull/943 
>>>>>> <https://github.com/apache/solr/pull/943> (for
>>>> SolrJ)
>>>>>> 
>>>>>> +1, I don't feel the value such changes bring to the project outweigh
>>>> the
>>>>>> disruption.
>>>>>> 
>>>>>> On Fri, Jul 29, 2022 at 9:26 PM Christine Poerschke (BLOOMBERG/
>> LONDON)
>>>> <
>>>>>> cpoersc...@bloomberg.net <mailto:cpoersc...@bloomberg.net>> wrote:
>>>>>> 
>>>>>>> PR 916 was a subset of PR 912 and I've just resolved its conflicts.
>>>>>>> 
>>>>>>> Also https://issues.apache.org/jira/browse/SOLR-16318 
>>>>>>> <https://issues.apache.org/jira/browse/SOLR-16318> started, in
>> case
>>>>>>> that helps.
>>>>>>> 
>>>>>>> Christine
>>>>>>> 
>>>>>>> From: dev@solr.apache.org <mailto:dev@solr.apache.org> At: 07/26/22 
>>>>>>> 15:10:03 UTC+1:00To:
>>>>>>> dev@solr.apache.org <mailto:dev@solr.apache.org>
>>>>>>> Subject: Re: Cleaning up IntelliJ warnings in code base
>>>>>>> 
>>>>>>> Not sure about https://github.com/apache/solr/pull/916 
>>>>>>> <https://github.com/apache/solr/pull/916> but
>>>>>>> https://github.com/apache/solr/pull/912 
>>>>>>> <https://github.com/apache/solr/pull/912> conflicts in a ton of plac

Re: Cleaning up IntelliJ warnings in code base

[David Smiley]

nk we can all agree that the Solr codebase can be a mess, and
> things
> >>> are not always done the way that they should be. Projects need
> >> maintenance
> >>> in order to survive. I think it's great that Eric is putting in
> >> tremendous
> >>> time and effort in order to improve the project in a pretty thankless
> >> way.
> >>>
> >>> Anyways happy to entertain further discussion on the topic, but I think
> >> the
> >>> new strategy is the best compromise of moving forward without making
> >> things
> >>> hard for others trying to contribute.
> >>>
> >>> - Houston
> >>>
> >>> On Sat, Jul 30, 2022 at 4:38 PM Ishan Chattopadhyaya <
> >>> ichattopadhy...@gmail.com> wrote:
> >>>
> >>>>> I ask that you please suspend sweeping changes because they are a
> real
> >>>> impediment to other branches/PRs that move lots of files.  This is
> >>>> happening right now: https://github.com/apache/solr/pull/943 (for
> >> SolrJ)
> >>>>
> >>>> +1, I don't feel the value such changes bring to the project outweigh
> >> the
> >>>> disruption.
> >>>>
> >>>> On Fri, Jul 29, 2022 at 9:26 PM Christine Poerschke (BLOOMBERG/
> LONDON)
> >> <
> >>>> cpoersc...@bloomberg.net> wrote:
> >>>>
> >>>>> PR 916 was a subset of PR 912 and I've just resolved its conflicts.
> >>>>>
> >>>>> Also https://issues.apache.org/jira/browse/SOLR-16318 started, in
> case
> >>>>> that helps.
> >>>>>
> >>>>> Christine
> >>>>>
> >>>>> From: dev@solr.apache.org At: 07/26/22 15:10:03 UTC+1:00To:
> >>>>> dev@solr.apache.org
> >>>>> Subject: Re: Cleaning up IntelliJ warnings in code base
> >>>>>
> >>>>> Not sure about https://github.com/apache/solr/pull/916 but
> >>>>> https://github.com/apache/solr/pull/912 conflicts in a ton of places
> >> and
> >>>>> haven't looked at updating it.
> >>>>>
> >>>>> Kevin Risden
> >>>>>
> >>>>>
> >>>>> On Tue, Jul 26, 2022 at 9:51 AM Eric Pugh <
> >>>> ep...@opensourceconnections.com
> >>>>>>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi all….   Are there any updates to the two PR’s related to WIP
> about
> >>>>>> updating to JDK 11 features?
> >>>>>>
> >>>>>> Once I’m done with https://issues.apache.org/jira/browse/SOLR-16300
> <
> >>>>>> https://issues.apache.org/jira/browse/SOLR-16300> Migrate from
> >>>>> deprecated
> >>>>>> assertThat() to org.hamcrest.MatcherAssert.assertThat(), it looks
> like
> >>>>> MANY
> >>>>>> of the remaining things to do all are related to upgrading to more
> >>>> modern
> >>>>>> JDK language features….
> >>>>>>
> >>>>>> I’m happy to do that, but don’t want to step on the work that is
> >>>>> progress?
> >>>>>>
> >>>>>>
> >>>>>> Eric
> >>>>>>
> >>>>>>> On Jul 4, 2022, at 2:23 PM, Eric Pugh <
> >>>> ep...@opensourceconnections.com
> >>>>>>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> I wanted to share a quick update!
> >>>>>>>
> >>>>>>> First off though, thanks Christine for reviewing many of the PR’s
> of
> >>>>>> been pushing up.As I’ve been editing the files I’ve found myself
> >>>>>> thinking….   WWCD in this situation[1]?
> >>>>>>>
> >>>>>>> Here are the PR’s that are getting close, and I’m just looking for
> >>>> some
> >>>>>> LGTM’s:
> >>>>>>>
> >>>>>>> * SOLR-16281: review boxing unboxing <
> >>>>>> https://github.com/apache/solr/pull/930>
> >>>>>>> * SOLR-16280: simplify for loop <
> >>>>> https://github.com/apache/solr/pull/929
> >>>>>>>
> >>>&

Re: Cleaning up IntelliJ warnings in code base

[Eric Pugh]

 right now: https://github.com/apache/solr/pull/943 (for
>> SolrJ)
>>>> 
>>>> +1, I don't feel the value such changes bring to the project outweigh
>> the
>>>> disruption.
>>>> 
>>>> On Fri, Jul 29, 2022 at 9:26 PM Christine Poerschke (BLOOMBERG/ LONDON)
>> <
>>>> cpoersc...@bloomberg.net> wrote:
>>>> 
>>>>> PR 916 was a subset of PR 912 and I've just resolved its conflicts.
>>>>> 
>>>>> Also https://issues.apache.org/jira/browse/SOLR-16318 started, in case
>>>>> that helps.
>>>>> 
>>>>> Christine
>>>>> 
>>>>> From: dev@solr.apache.org At: 07/26/22 15:10:03 UTC+1:00To:
>>>>> dev@solr.apache.org
>>>>> Subject: Re: Cleaning up IntelliJ warnings in code base
>>>>> 
>>>>> Not sure about https://github.com/apache/solr/pull/916 but
>>>>> https://github.com/apache/solr/pull/912 conflicts in a ton of places
>> and
>>>>> haven't looked at updating it.
>>>>> 
>>>>> Kevin Risden
>>>>> 
>>>>> 
>>>>> On Tue, Jul 26, 2022 at 9:51 AM Eric Pugh <
>>>> ep...@opensourceconnections.com
>>>>>> 
>>>>> wrote:
>>>>> 
>>>>>> Hi all….   Are there any updates to the two PR’s related to WIP about
>>>>>> updating to JDK 11 features?
>>>>>> 
>>>>>> Once I’m done with https://issues.apache.org/jira/browse/SOLR-16300 <
>>>>>> https://issues.apache.org/jira/browse/SOLR-16300> Migrate from
>>>>> deprecated
>>>>>> assertThat() to org.hamcrest.MatcherAssert.assertThat(), it looks like
>>>>> MANY
>>>>>> of the remaining things to do all are related to upgrading to more
>>>> modern
>>>>>> JDK language features….
>>>>>> 
>>>>>> I’m happy to do that, but don’t want to step on the work that is
>>>>> progress?
>>>>>> 
>>>>>> 
>>>>>> Eric
>>>>>> 
>>>>>>> On Jul 4, 2022, at 2:23 PM, Eric Pugh <
>>>> ep...@opensourceconnections.com
>>>>>> 
>>>>>> wrote:
>>>>>>> 
>>>>>>> I wanted to share a quick update!
>>>>>>> 
>>>>>>> First off though, thanks Christine for reviewing many of the PR’s of
>>>>>> been pushing up.As I’ve been editing the files I’ve found myself
>>>>>> thinking….   WWCD in this situation[1]?
>>>>>>> 
>>>>>>> Here are the PR’s that are getting close, and I’m just looking for
>>>> some
>>>>>> LGTM’s:
>>>>>>> 
>>>>>>> * SOLR-16281: review boxing unboxing <
>>>>>> https://github.com/apache/solr/pull/930>
>>>>>>> * SOLR-16280: simplify for loop <
>>>>> https://github.com/apache/solr/pull/929
>>>>>>> 
>>>>>>> * SOLR-16278: remove unused declarations <
>>>>>> https://github.com/apache/solr/pull/927>
>>>>>>> * SOLR-16223: unused throws identified by IntelliJ (round 2) <
>>>>>> https://github.com/apache/solr/pull/926>.  <— I learned how to
>> use
>>>>>> IntelliJ better after doing the first round of redundant throws review
>>>>> ;-)
>>>>>>> * SOLR-16275 use standard charset instead of string forName version <
>>>>>> https://github.com/apache/solr/pull/925>
>>>>>>> * SOLR-16276: redundant variable in test <
>>>>>> https://github.com/apache/solr/pull/924>
>>>>>>> 
>>>>>>> 
>>>>>>> Also, as I am moving forward, I saw two PR’s that I don’t quite
>>>>>> understand, and I don’t want to step on their toes:
>>>>>>> 
>>>>>>> experimental sub-set 1 of "WIP - Use up to JDK 11 features” <
>>>>>> https://github.com/apache/solr/pull/916> and WIP - Use up to JDK 11
>>>>>> features <https://github.com/apache/solr/pull/912>, these each both
>>>> look
>>>>>> to move us up to modern Java standards across all the code….I’m
>>>>>> wondering though if some of 

Re: Cleaning up IntelliJ warnings in code base

[David Smiley]

Do other projects do that?  FWIW I tailor an IDE-wide inspection profile to
my liking, tweaking what's enabled and also the severity level to reduce
red-ness when I don't think it's warranted.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Tue, Aug 23, 2022 at 12:34 PM Eric Pugh 
wrote:

> I was thinking about how to make this process less painful, and maybe how
> to capture what we as a community think are warnings that we actually care
> about.
>
> IntelliJ appears to have “Inspection Profiles”
> https://www.jetbrains.com/help/idea/code-inspection.html#access-inspections-and-settings
> <
> https://www.jetbrains.com/help/idea/code-inspection.html#access-inspections-and-settings>
> that we can customize.
>
> It appears that there is a .idea/InspectionProfiles directory that maybe
> our gradle build could somehow tie into…. Run gradlew idea and have our
> inspection file setup for us?
>
>
>
>
> > On Aug 18, 2022, at 12:03 AM, Houston Putman  wrote:
> >
> > I completely understand your concern and frustration for the
> > solrj-zookeeper PR David, it's been in the works for a while, and these
> > refactorings are very hard on you and the contributor you are working
> with.
> >
> > Eric and I talked, and given that there are very few giant PRs that are
> in
> > progress, we agreed this work can likely continue after the
> solrj-zookeeper
> > PR is merged.
> >
> > Going forward though, I think the strategy is going to be to attack
> > package-by-package (addressing all issues in that package), instead of
> > intelliJ issue by intelliJ issue (addressing all packages at the same
> > time). That way, the PRs are confined to a specific area, so for example
> > the solrj-zookeeper work would be unaffected unless Eric decided to
> tackle
> > the solrj packages, which he could obviously postpone.
> >
> > I think we can all agree that the Solr codebase can be a mess, and things
> > are not always done the way that they should be. Projects need
> maintenance
> > in order to survive. I think it's great that Eric is putting in
> tremendous
> > time and effort in order to improve the project in a pretty thankless
> way.
> >
> > Anyways happy to entertain further discussion on the topic, but I think
> the
> > new strategy is the best compromise of moving forward without making
> things
> > hard for others trying to contribute.
> >
> > - Houston
> >
> > On Sat, Jul 30, 2022 at 4:38 PM Ishan Chattopadhyaya <
> > ichattopadhy...@gmail.com> wrote:
> >
> >>> I ask that you please suspend sweeping changes because they are a real
> >> impediment to other branches/PRs that move lots of files.  This is
> >> happening right now: https://github.com/apache/solr/pull/943 (for
> SolrJ)
> >>
> >> +1, I don't feel the value such changes bring to the project outweigh
> the
> >> disruption.
> >>
> >> On Fri, Jul 29, 2022 at 9:26 PM Christine Poerschke (BLOOMBERG/ LONDON)
> <
> >> cpoersc...@bloomberg.net> wrote:
> >>
> >>> PR 916 was a subset of PR 912 and I've just resolved its conflicts.
> >>>
> >>> Also https://issues.apache.org/jira/browse/SOLR-16318 started, in case
> >>> that helps.
> >>>
> >>> Christine
> >>>
> >>> From: dev@solr.apache.org At: 07/26/22 15:10:03 UTC+1:00To:
> >>> dev@solr.apache.org
> >>> Subject: Re: Cleaning up IntelliJ warnings in code base
> >>>
> >>> Not sure about https://github.com/apache/solr/pull/916 but
> >>> https://github.com/apache/solr/pull/912 conflicts in a ton of places
> and
> >>> haven't looked at updating it.
> >>>
> >>> Kevin Risden
> >>>
> >>>
> >>> On Tue, Jul 26, 2022 at 9:51 AM Eric Pugh <
> >> ep...@opensourceconnections.com
> >>>>
> >>> wrote:
> >>>
> >>>> Hi all….   Are there any updates to the two PR’s related to WIP about
> >>>> updating to JDK 11 features?
> >>>>
> >>>> Once I’m done with https://issues.apache.org/jira/browse/SOLR-16300 <
> >>>> https://issues.apache.org/jira/browse/SOLR-16300> Migrate from
> >>> deprecated
> >>>> assertThat() to org.hamcrest.MatcherAssert.assertThat(), it looks like
> >>> MANY
> >>>> of the remaining things to do all are related to upgrading to more
> >> modern

Re: Cleaning up IntelliJ warnings in code base

[Eric Pugh]

I was thinking about how to make this process less painful, and maybe how to 
capture what we as a community think are warnings that we actually care about.  
 

IntelliJ appears to have “Inspection Profiles” 
https://www.jetbrains.com/help/idea/code-inspection.html#access-inspections-and-settings
 
<https://www.jetbrains.com/help/idea/code-inspection.html#access-inspections-and-settings>
 that we can customize.

It appears that there is a .idea/InspectionProfiles directory that maybe our 
gradle build could somehow tie into…. Run gradlew idea and have our 
inspection file setup for us?   




> On Aug 18, 2022, at 12:03 AM, Houston Putman  wrote:
> 
> I completely understand your concern and frustration for the
> solrj-zookeeper PR David, it's been in the works for a while, and these
> refactorings are very hard on you and the contributor you are working with.
> 
> Eric and I talked, and given that there are very few giant PRs that are in
> progress, we agreed this work can likely continue after the solrj-zookeeper
> PR is merged.
> 
> Going forward though, I think the strategy is going to be to attack
> package-by-package (addressing all issues in that package), instead of
> intelliJ issue by intelliJ issue (addressing all packages at the same
> time). That way, the PRs are confined to a specific area, so for example
> the solrj-zookeeper work would be unaffected unless Eric decided to tackle
> the solrj packages, which he could obviously postpone.
> 
> I think we can all agree that the Solr codebase can be a mess, and things
> are not always done the way that they should be. Projects need maintenance
> in order to survive. I think it's great that Eric is putting in tremendous
> time and effort in order to improve the project in a pretty thankless way.
> 
> Anyways happy to entertain further discussion on the topic, but I think the
> new strategy is the best compromise of moving forward without making things
> hard for others trying to contribute.
> 
> - Houston
> 
> On Sat, Jul 30, 2022 at 4:38 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
> 
>>> I ask that you please suspend sweeping changes because they are a real
>> impediment to other branches/PRs that move lots of files.  This is
>> happening right now: https://github.com/apache/solr/pull/943 (for SolrJ)
>> 
>> +1, I don't feel the value such changes bring to the project outweigh the
>> disruption.
>> 
>> On Fri, Jul 29, 2022 at 9:26 PM Christine Poerschke (BLOOMBERG/ LONDON) <
>> cpoersc...@bloomberg.net> wrote:
>> 
>>> PR 916 was a subset of PR 912 and I've just resolved its conflicts.
>>> 
>>> Also https://issues.apache.org/jira/browse/SOLR-16318 started, in case
>>> that helps.
>>> 
>>> Christine
>>> 
>>> From: dev@solr.apache.org At: 07/26/22 15:10:03 UTC+1:00To:
>>> dev@solr.apache.org
>>> Subject: Re: Cleaning up IntelliJ warnings in code base
>>> 
>>> Not sure about https://github.com/apache/solr/pull/916 but
>>> https://github.com/apache/solr/pull/912 conflicts in a ton of places and
>>> haven't looked at updating it.
>>> 
>>> Kevin Risden
>>> 
>>> 
>>> On Tue, Jul 26, 2022 at 9:51 AM Eric Pugh <
>> ep...@opensourceconnections.com
>>>> 
>>> wrote:
>>> 
>>>> Hi all….   Are there any updates to the two PR’s related to WIP about
>>>> updating to JDK 11 features?
>>>> 
>>>> Once I’m done with https://issues.apache.org/jira/browse/SOLR-16300 <
>>>> https://issues.apache.org/jira/browse/SOLR-16300> Migrate from
>>> deprecated
>>>> assertThat() to org.hamcrest.MatcherAssert.assertThat(), it looks like
>>> MANY
>>>> of the remaining things to do all are related to upgrading to more
>> modern
>>>> JDK language features….
>>>> 
>>>> I’m happy to do that, but don’t want to step on the work that is
>>> progress?
>>>> 
>>>> 
>>>> Eric
>>>> 
>>>>> On Jul 4, 2022, at 2:23 PM, Eric Pugh <
>> ep...@opensourceconnections.com
>>>> 
>>>> wrote:
>>>>> 
>>>>> I wanted to share a quick update!
>>>>> 
>>>>> First off though, thanks Christine for reviewing many of the PR’s of
>>>> been pushing up.As I’ve been editing the files I’ve found myself
>>>> thinking….   WWCD in this situation[1]?
>>>>> 
>>>>> Here are the PR’s that are getting close, and I’m just looking for
>&g

Re: Cleaning up IntelliJ warnings in code base

[Houston Putman]

I completely understand your concern and frustration for the
solrj-zookeeper PR David, it's been in the works for a while, and these
refactorings are very hard on you and the contributor you are working with.

Eric and I talked, and given that there are very few giant PRs that are in
progress, we agreed this work can likely continue after the solrj-zookeeper
PR is merged.

Going forward though, I think the strategy is going to be to attack
package-by-package (addressing all issues in that package), instead of
intelliJ issue by intelliJ issue (addressing all packages at the same
time). That way, the PRs are confined to a specific area, so for example
the solrj-zookeeper work would be unaffected unless Eric decided to tackle
the solrj packages, which he could obviously postpone.

I think we can all agree that the Solr codebase can be a mess, and things
are not always done the way that they should be. Projects need maintenance
in order to survive. I think it's great that Eric is putting in tremendous
time and effort in order to improve the project in a pretty thankless way.

Anyways happy to entertain further discussion on the topic, but I think the
new strategy is the best compromise of moving forward without making things
hard for others trying to contribute.

- Houston

On Sat, Jul 30, 2022 at 4:38 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> > I ask that you please suspend sweeping changes because they are a real
> impediment to other branches/PRs that move lots of files.  This is
> happening right now: https://github.com/apache/solr/pull/943 (for SolrJ)
>
> +1, I don't feel the value such changes bring to the project outweigh the
> disruption.
>
> On Fri, Jul 29, 2022 at 9:26 PM Christine Poerschke (BLOOMBERG/ LONDON) <
> cpoersc...@bloomberg.net> wrote:
>
> > PR 916 was a subset of PR 912 and I've just resolved its conflicts.
> >
> > Also https://issues.apache.org/jira/browse/SOLR-16318 started, in case
> > that helps.
> >
> > Christine
> >
> > From: dev@solr.apache.org At: 07/26/22 15:10:03 UTC+1:00To:
> > dev@solr.apache.org
> > Subject: Re: Cleaning up IntelliJ warnings in code base
> >
> > Not sure about https://github.com/apache/solr/pull/916 but
> > https://github.com/apache/solr/pull/912 conflicts in a ton of places and
> > haven't looked at updating it.
> >
> > Kevin Risden
> >
> >
> > On Tue, Jul 26, 2022 at 9:51 AM Eric Pugh <
> ep...@opensourceconnections.com
> > >
> > wrote:
> >
> > > Hi all….   Are there any updates to the two PR’s related to WIP about
> > > updating to JDK 11 features?
> > >
> > > Once I’m done with https://issues.apache.org/jira/browse/SOLR-16300 <
> > > https://issues.apache.org/jira/browse/SOLR-16300> Migrate from
> > deprecated
> > > assertThat() to org.hamcrest.MatcherAssert.assertThat(), it looks like
> > MANY
> > > of the remaining things to do all are related to upgrading to more
> modern
> > > JDK language features….
> > >
> > > I’m happy to do that, but don’t want to step on the work that is
> > progress?
> > >
> > >
> > > Eric
> > >
> > > > On Jul 4, 2022, at 2:23 PM, Eric Pugh <
> ep...@opensourceconnections.com
> > >
> > > wrote:
> > > >
> > > > I wanted to share a quick update!
> > > >
> > > > First off though, thanks Christine for reviewing many of the PR’s of
> > > been pushing up.As I’ve been editing the files I’ve found myself
> > > thinking….   WWCD in this situation[1]?
> > > >
> > > > Here are the PR’s that are getting close, and I’m just looking for
> some
> > > LGTM’s:
> > > >
> > > > * SOLR-16281: review boxing unboxing <
> > > https://github.com/apache/solr/pull/930>
> > > > * SOLR-16280: simplify for loop <
> > https://github.com/apache/solr/pull/929
> > > >
> > > > * SOLR-16278: remove unused declarations <
> > > https://github.com/apache/solr/pull/927>
> > > > * SOLR-16223: unused throws identified by IntelliJ (round 2) <
> > > https://github.com/apache/solr/pull/926>.  <— I learned how to use
> > > IntelliJ better after doing the first round of redundant throws review
> > ;-)
> > > > * SOLR-16275 use standard charset instead of string forName version <
> > > https://github.com/apache/solr/pull/925>
> > > > * SOLR-16276: redundant variable in test <
> > > https://github.com/apache/solr/pull/924>
> > > >
> > >

Re: Cleaning up IntelliJ warnings in code base

[Ishan Chattopadhyaya]

> I ask that you please suspend sweeping changes because they are a real
impediment to other branches/PRs that move lots of files.  This is
happening right now: https://github.com/apache/solr/pull/943 (for SolrJ)

+1, I don't feel the value such changes bring to the project outweigh the
disruption.

On Fri, Jul 29, 2022 at 9:26 PM Christine Poerschke (BLOOMBERG/ LONDON) <
cpoersc...@bloomberg.net> wrote:

> PR 916 was a subset of PR 912 and I've just resolved its conflicts.
>
> Also https://issues.apache.org/jira/browse/SOLR-16318 started, in case
> that helps.
>
> Christine
>
> From: dev@solr.apache.org At: 07/26/22 15:10:03 UTC+1:00To:
> dev@solr.apache.org
> Subject: Re: Cleaning up IntelliJ warnings in code base
>
> Not sure about https://github.com/apache/solr/pull/916 but
> https://github.com/apache/solr/pull/912 conflicts in a ton of places and
> haven't looked at updating it.
>
> Kevin Risden
>
>
> On Tue, Jul 26, 2022 at 9:51 AM Eric Pugh  >
> wrote:
>
> > Hi all….   Are there any updates to the two PR’s related to WIP about
> > updating to JDK 11 features?
> >
> > Once I’m done with https://issues.apache.org/jira/browse/SOLR-16300 <
> > https://issues.apache.org/jira/browse/SOLR-16300> Migrate from
> deprecated
> > assertThat() to org.hamcrest.MatcherAssert.assertThat(), it looks like
> MANY
> > of the remaining things to do all are related to upgrading to more modern
> > JDK language features….
> >
> > I’m happy to do that, but don’t want to step on the work that is
> progress?
> >
> >
> > Eric
> >
> > > On Jul 4, 2022, at 2:23 PM, Eric Pugh  >
> > wrote:
> > >
> > > I wanted to share a quick update!
> > >
> > > First off though, thanks Christine for reviewing many of the PR’s of
> > been pushing up.As I’ve been editing the files I’ve found myself
> > thinking….   WWCD in this situation[1]?
> > >
> > > Here are the PR’s that are getting close, and I’m just looking for some
> > LGTM’s:
> > >
> > > * SOLR-16281: review boxing unboxing <
> > https://github.com/apache/solr/pull/930>
> > > * SOLR-16280: simplify for loop <
> https://github.com/apache/solr/pull/929
> > >
> > > * SOLR-16278: remove unused declarations <
> > https://github.com/apache/solr/pull/927>
> > > * SOLR-16223: unused throws identified by IntelliJ (round 2) <
> > https://github.com/apache/solr/pull/926>.  <— I learned how to use
> > IntelliJ better after doing the first round of redundant throws review
> ;-)
> > > * SOLR-16275 use standard charset instead of string forName version <
> > https://github.com/apache/solr/pull/925>
> > > * SOLR-16276: redundant variable in test <
> > https://github.com/apache/solr/pull/924>
> > >
> > >
> > > Also, as I am moving forward, I saw two PR’s that I don’t quite
> > understand, and I don’t want to step on their toes:
> > >
> > > experimental sub-set 1 of "WIP - Use up to JDK 11 features” <
> > https://github.com/apache/solr/pull/916> and WIP - Use up to JDK 11
> > features <https://github.com/apache/solr/pull/912>, these each both look
> > to move us up to modern Java standards across all the code….I’m
> > wondering though if some of the work I’m doing is going to collide, like
> > SOLR-16281?Should we prioritize one of these efforts to get to done
> > done?There appears to be a TON of great stuff in these updates to
> JDK11
> > features, so would love to see them get in sooner versus later, and then
> I
> > can go back to cleaning up what remains…. <
> > https://github.com/apache/solr/pull/916#partial-pull-merging>
> > >
> > > ERic
> > >
> > >  <https://github.com/apache/solr/pull/912#partial-pull-merging> <
> > https://github.com/apache/solr/pull/912#partial-pull-merging>
> > >
> > >
> > >
> > > [1] WWCD:  What Would Christine Do?
> > >
> > >> On Jun 27, 2022, at 5:41 PM, Eric Pugh <
> ep...@opensourceconnections.com
> > <mailto:ep...@opensourceconnections.com>> wrote:
> > >>
> > >> I pushed up some more PR’s for warnings from IntelliJ.
> > >>
> > >> Here are the ones that if folks agree, are ready for merging.
> > >>
> > >> * SOLR-162680: toString is not required when crafting a string
> message <
> > https://github.com/apache/solr/pull/922>
> > >> * SOLR-16224: class level variables t

Re: Cleaning up IntelliJ warnings in code base

[Christine Poerschke (BLOOMBERG/ LONDON)]

PR 916 was a subset of PR 912 and I've just resolved its conflicts.

Also https://issues.apache.org/jira/browse/SOLR-16318 started, in case that 
helps.

Christine

From: dev@solr.apache.org At: 07/26/22 15:10:03 UTC+1:00To:  dev@solr.apache.org
Subject: Re: Cleaning up IntelliJ warnings in code base

Not sure about https://github.com/apache/solr/pull/916 but
https://github.com/apache/solr/pull/912 conflicts in a ton of places and
haven't looked at updating it.

Kevin Risden


On Tue, Jul 26, 2022 at 9:51 AM Eric Pugh 
wrote:

> Hi all….   Are there any updates to the two PR’s related to WIP about
> updating to JDK 11 features?
>
> Once I’m done with https://issues.apache.org/jira/browse/SOLR-16300 <
> https://issues.apache.org/jira/browse/SOLR-16300> Migrate from deprecated
> assertThat() to org.hamcrest.MatcherAssert.assertThat(), it looks like MANY
> of the remaining things to do all are related to upgrading to more modern
> JDK language features….
>
> I’m happy to do that, but don’t want to step on the work that is progress?
>
>
> Eric
>
> > On Jul 4, 2022, at 2:23 PM, Eric Pugh 
> wrote:
> >
> > I wanted to share a quick update!
> >
> > First off though, thanks Christine for reviewing many of the PR’s of
> been pushing up.As I’ve been editing the files I’ve found myself
> thinking….   WWCD in this situation[1]?
> >
> > Here are the PR’s that are getting close, and I’m just looking for some
> LGTM’s:
> >
> > * SOLR-16281: review boxing unboxing <
> https://github.com/apache/solr/pull/930>
> > * SOLR-16280: simplify for loop <https://github.com/apache/solr/pull/929
> >
> > * SOLR-16278: remove unused declarations <
> https://github.com/apache/solr/pull/927>
> > * SOLR-16223: unused throws identified by IntelliJ (round 2) <
> https://github.com/apache/solr/pull/926>.  <— I learned how to use
> IntelliJ better after doing the first round of redundant throws review ;-)
> > * SOLR-16275 use standard charset instead of string forName version <
> https://github.com/apache/solr/pull/925>
> > * SOLR-16276: redundant variable in test <
> https://github.com/apache/solr/pull/924>
> >
> >
> > Also, as I am moving forward, I saw two PR’s that I don’t quite
> understand, and I don’t want to step on their toes:
> >
> > experimental sub-set 1 of "WIP - Use up to JDK 11 features” <
> https://github.com/apache/solr/pull/916> and WIP - Use up to JDK 11
> features <https://github.com/apache/solr/pull/912>, these each both look
> to move us up to modern Java standards across all the code….I’m
> wondering though if some of the work I’m doing is going to collide, like
> SOLR-16281?Should we prioritize one of these efforts to get to done
> done?There appears to be a TON of great stuff in these updates to JDK11
> features, so would love to see them get in sooner versus later, and then I
> can go back to cleaning up what remains…. <
> https://github.com/apache/solr/pull/916#partial-pull-merging>
> >
> > ERic
> >
> >  <https://github.com/apache/solr/pull/912#partial-pull-merging> <
> https://github.com/apache/solr/pull/912#partial-pull-merging>
> >
> >
> >
> > [1] WWCD:  What Would Christine Do?
> >
> >> On Jun 27, 2022, at 5:41 PM, Eric Pugh  <mailto:ep...@opensourceconnections.com>> wrote:
> >>
> >> I pushed up some more PR’s for warnings from IntelliJ.
> >>
> >> Here are the ones that if folks agree, are ready for merging.
> >>
> >> * SOLR-162680: toString is not required when crafting a string message <
> https://github.com/apache/solr/pull/922>
> >> * SOLR-16224: class level variables that can be safely made local, and
> are boilerpl… <https://github.com/apache/solr/pull/921>
> >> * SOLR-16269 clean up use of final keyword <
> https://github.com/apache/solr/pull/919>
> >> * SOLR-16270: address dangling javadocs <
> https://github.com/apache/solr/pull/918>
> >>
> >> Another one that I am looking at is to eliminate all of the import
> java.util.*;  type imports, which I believe is what we have in the main
> code base.  I wanted to make sure that is a pattern to follow in the unit
> tests too?
> >>
> >> SOLR-16271: clean up imports (WIP) <
> https://github.com/apache/solr/pull/920>
> >>
> >> Eric
> >>
> >>  <https://github.com/apache/solr/pull/918#partial-pull-merging> <
> https://github.com/apache/solr/pull/918#partial-pull-merging>
> >>  <https://github.com/apache/solr/pull/919#partial-pul

Re: Cleaning up IntelliJ warnings in code base

[Eric Pugh]

Sure!   

I wonder if there is a better way to organize these types of changes in the 
future…..?   I would love to get the rest of the warnings dealt with at some 
point.

Eric

> On Jul 26, 2022, at 2:34 PM, David Smiley  wrote:
> 
> I ask that you please suspend sweeping changes because they are a real 
> impediment to other branches/PRs that move lots of files.  This is happening 
> right now: https://github.com/apache/solr/pull/943 
>  (for SolrJ)
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> 
> 
> On Tue, Jul 26, 2022 at 10:13 AM Eric Pugh  > wrote:
> I just checked what IntelliJ is flagging as language related in the core 
> tests, and it’s a lot!
> 
> 
> 
> There 5160 Java warnings in the core tests, so getting the language updated 
> would knock out 16% of the warnings!
> 
>> On Jul 26, 2022, at 9:51 AM, Eric Pugh > > wrote:
>> 
>> Hi all….   Are there any updates to the two PR’s related to WIP about 
>> updating to JDK 11 features?
>> 
>> Once I’m done with https://issues.apache.org/jira/browse/SOLR-16300 
>>  Migrate from deprecated 
>> assertThat() to org.hamcrest.MatcherAssert.assertThat(), it looks like MANY 
>> of the remaining things to do all are related to upgrading to more modern 
>> JDK language features….
>> 
>> I’m happy to do that, but don’t want to step on the work that is progress?
>> 
>> 
>> Eric
>> 
>>> On Jul 4, 2022, at 2:23 PM, Eric Pugh >> > wrote:
>>> 
>>> I wanted to share a quick update!
>>> 
>>> First off though, thanks Christine for reviewing many of the PR’s of been 
>>> pushing up.As I’ve been editing the files I’ve found myself thinking….  
>>>  WWCD in this situation[1]?
>>> 
>>> Here are the PR’s that are getting close, and I’m just looking for some 
>>> LGTM’s:
>>> 
>>> * SOLR-16281: review boxing unboxing 
>>> 
>>> * SOLR-16280: simplify for loop 
>>> * SOLR-16278: remove unused declarations 
>>> 
>>> * SOLR-16223: unused throws identified by IntelliJ (round 2) 
>>> .  <— I learned how to use 
>>> IntelliJ better after doing the first round of redundant throws review ;-)
>>> * SOLR-16275 use standard charset instead of string forName version 
>>> 
>>> * SOLR-16276: redundant variable in test 
>>> 
>>> 
>>> 
>>> Also, as I am moving forward, I saw two PR’s that I don’t quite understand, 
>>> and I don’t want to step on their toes:
>>> 
>>> experimental sub-set 1 of "WIP - Use up to JDK 11 features” 
>>>  and WIP - Use up to JDK 11 
>>> features , these each both look to 
>>> move us up to modern Java standards across all the code….I’m wondering 
>>> though if some of the work I’m doing is going to collide, like SOLR-16281?  
>>>   Should we prioritize one of these efforts to get to done done?There 
>>> appears to be a TON of great stuff in these updates to JDK11 features, so 
>>> would love to see them get in sooner versus later, and then I can go back 
>>> to cleaning up what remains…. 
>>> 
>>> 
>>> ERic
>>> 
>>>   
>>> 
>>> 
>>> 
>>> 
>>> [1] WWCD:  What Would Christine Do? 
>>> 
 On Jun 27, 2022, at 5:41 PM, Eric Pugh >>> > wrote:
 
 I pushed up some more PR’s for warnings from IntelliJ.
 
 Here are the ones that if folks agree, are ready for merging.
 
 * SOLR-162680: toString is not required when crafting a string message 
 
 * SOLR-16224: class level variables that can be safely made local, and are 
 boilerpl… 
 * SOLR-16269 clean up use of final keyword 
 
 * SOLR-16270: address dangling javadocs 
 
 
 Another one that I am looking at is to eliminate all of the import 
 java.util.*;  type imports, which I believe is what we have in the main 
 code base.  I wanted to make sure that is a pattern to follow in the unit 
 tests too?
 
 SOLR-16271: clean up imports (WIP) 
 
 
 Eric
 
   
 

Re: Cleaning up IntelliJ warnings in code base

[Kevin Risden]

Not sure about https://github.com/apache/solr/pull/916 but
https://github.com/apache/solr/pull/912 conflicts in a ton of places and
haven't looked at updating it.

Kevin Risden


On Tue, Jul 26, 2022 at 9:51 AM Eric Pugh 
wrote:

> Hi all….   Are there any updates to the two PR’s related to WIP about
> updating to JDK 11 features?
>
> Once I’m done with https://issues.apache.org/jira/browse/SOLR-16300 <
> https://issues.apache.org/jira/browse/SOLR-16300> Migrate from deprecated
> assertThat() to org.hamcrest.MatcherAssert.assertThat(), it looks like MANY
> of the remaining things to do all are related to upgrading to more modern
> JDK language features….
>
> I’m happy to do that, but don’t want to step on the work that is progress?
>
>
> Eric
>
> > On Jul 4, 2022, at 2:23 PM, Eric Pugh 
> wrote:
> >
> > I wanted to share a quick update!
> >
> > First off though, thanks Christine for reviewing many of the PR’s of
> been pushing up.As I’ve been editing the files I’ve found myself
> thinking….   WWCD in this situation[1]?
> >
> > Here are the PR’s that are getting close, and I’m just looking for some
> LGTM’s:
> >
> > * SOLR-16281: review boxing unboxing <
> https://github.com/apache/solr/pull/930>
> > * SOLR-16280: simplify for loop  >
> > * SOLR-16278: remove unused declarations <
> https://github.com/apache/solr/pull/927>
> > * SOLR-16223: unused throws identified by IntelliJ (round 2) <
> https://github.com/apache/solr/pull/926>.  <— I learned how to use
> IntelliJ better after doing the first round of redundant throws review ;-)
> > * SOLR-16275 use standard charset instead of string forName version <
> https://github.com/apache/solr/pull/925>
> > * SOLR-16276: redundant variable in test <
> https://github.com/apache/solr/pull/924>
> >
> >
> > Also, as I am moving forward, I saw two PR’s that I don’t quite
> understand, and I don’t want to step on their toes:
> >
> > experimental sub-set 1 of "WIP - Use up to JDK 11 features” <
> https://github.com/apache/solr/pull/916> and WIP - Use up to JDK 11
> features , these each both look
> to move us up to modern Java standards across all the code….I’m
> wondering though if some of the work I’m doing is going to collide, like
> SOLR-16281?Should we prioritize one of these efforts to get to done
> done?There appears to be a TON of great stuff in these updates to JDK11
> features, so would love to see them get in sooner versus later, and then I
> can go back to cleaning up what remains…. <
> https://github.com/apache/solr/pull/916#partial-pull-merging>
> >
> > ERic
> >
> >   <
> https://github.com/apache/solr/pull/912#partial-pull-merging>
> >
> >
> >
> > [1] WWCD:  What Would Christine Do?
> >
> >> On Jun 27, 2022, at 5:41 PM, Eric Pugh  > wrote:
> >>
> >> I pushed up some more PR’s for warnings from IntelliJ.
> >>
> >> Here are the ones that if folks agree, are ready for merging.
> >>
> >> * SOLR-162680: toString is not required when crafting a string message <
> https://github.com/apache/solr/pull/922>
> >> * SOLR-16224: class level variables that can be safely made local, and
> are boilerpl… 
> >> * SOLR-16269 clean up use of final keyword <
> https://github.com/apache/solr/pull/919>
> >> * SOLR-16270: address dangling javadocs <
> https://github.com/apache/solr/pull/918>
> >>
> >> Another one that I am looking at is to eliminate all of the import
> java.util.*;  type imports, which I believe is what we have in the main
> code base.  I wanted to make sure that is a pattern to follow in the unit
> tests too?
> >>
> >> SOLR-16271: clean up imports (WIP) <
> https://github.com/apache/solr/pull/920>
> >>
> >> Eric
> >>
> >>   <
> https://github.com/apache/solr/pull/918#partial-pull-merging>
> >>   <
> https://github.com/apache/solr/pull/919#partial-pull-merging>
> >>   <
> https://github.com/apache/solr/pull/921#partial-pull-merging>
> >>   <
> https://github.com/apache/solr/pull/922#partial-pull-merging>
> >>
> >>> On Jun 27, 2022, at 11:25 AM, Eric Pugh <
> ep...@opensourceconnections.com >
> wrote:
> >>>
> >>> Thanks David for the comments in the ticket, and it makes sense to
> treat stylistic warnings different from deprecations.
> >>>
> >>>
> >>>
>  On Jun 24, 2022, at 10:11 PM, David Smiley  > wrote:
> 
>  How to handle certain deprecations is IMO a different matter than
> stylistic-ish warnings.  I'll respond in SOLR-16263.
> 
>  ~ David Smiley
>  Apache Lucene/Solr Search Developer

Re: Cleaning up IntelliJ warnings in code base

[Eric Pugh]

Hi all….   Are there any updates to the two PR’s related to WIP about updating 
to JDK 11 features?

Once I’m done with https://issues.apache.org/jira/browse/SOLR-16300 
 Migrate from deprecated 
assertThat() to org.hamcrest.MatcherAssert.assertThat(), it looks like MANY of 
the remaining things to do all are related to upgrading to more modern JDK 
language features….

I’m happy to do that, but don’t want to step on the work that is progress?


Eric

> On Jul 4, 2022, at 2:23 PM, Eric Pugh  wrote:
> 
> I wanted to share a quick update!
> 
> First off though, thanks Christine for reviewing many of the PR’s of been 
> pushing up.As I’ve been editing the files I’ve found myself thinking….   
> WWCD in this situation[1]?
> 
> Here are the PR’s that are getting close, and I’m just looking for some 
> LGTM’s:
> 
> * SOLR-16281: review boxing unboxing 
> * SOLR-16280: simplify for loop 
> * SOLR-16278: remove unused declarations 
> 
> * SOLR-16223: unused throws identified by IntelliJ (round 2) 
> .  <— I learned how to use 
> IntelliJ better after doing the first round of redundant throws review ;-)
> * SOLR-16275 use standard charset instead of string forName version 
> 
> * SOLR-16276: redundant variable in test 
> 
> 
> 
> Also, as I am moving forward, I saw two PR’s that I don’t quite understand, 
> and I don’t want to step on their toes:
> 
> experimental sub-set 1 of "WIP - Use up to JDK 11 features” 
>  and WIP - Use up to JDK 11 features 
> , these each both look to move us up 
> to modern Java standards across all the code….I’m wondering though if 
> some of the work I’m doing is going to collide, like SOLR-16281?Should we 
> prioritize one of these efforts to get to done done?There appears to be a 
> TON of great stuff in these updates to JDK11 features, so would love to see 
> them get in sooner versus later, and then I can go back to cleaning up what 
> remains…. 
> 
> ERic
> 
>   
> 
> 
> 
> 
> [1] WWCD:  What Would Christine Do? 
> 
>> On Jun 27, 2022, at 5:41 PM, Eric Pugh > > wrote:
>> 
>> I pushed up some more PR’s for warnings from IntelliJ.
>> 
>> Here are the ones that if folks agree, are ready for merging.
>> 
>> * SOLR-162680: toString is not required when crafting a string message 
>> 
>> * SOLR-16224: class level variables that can be safely made local, and are 
>> boilerpl… 
>> * SOLR-16269 clean up use of final keyword 
>> 
>> * SOLR-16270: address dangling javadocs 
>> 
>> 
>> Another one that I am looking at is to eliminate all of the import 
>> java.util.*;  type imports, which I believe is what we have in the main code 
>> base.  I wanted to make sure that is a pattern to follow in the unit tests 
>> too?
>> 
>> SOLR-16271: clean up imports (WIP) 
>> 
>> Eric
>> 
>>   
>> 
>>   
>> 
>>   
>> 
>>   
>> 
>> 
>>> On Jun 27, 2022, at 11:25 AM, Eric Pugh >> > wrote:
>>> 
>>> Thanks David for the comments in the ticket, and it makes sense to treat 
>>> stylistic warnings different from deprecations.
>>> 
>>> 
>>> 
 On Jun 24, 2022, at 10:11 PM, David Smiley >>> > wrote:
 
 How to handle certain deprecations is IMO a different matter than 
 stylistic-ish warnings.  I'll respond in SOLR-16263.
 
 ~ David Smiley
 Apache Lucene/Solr Search Developer
 http://www.linkedin.com/in/davidwsmiley 
 
 
 On Fri, Jun 24, 2022 at 12:19 PM Eric Pugh 
 mailto:ep...@opensourceconnections.com>> 
 wrote:
 I created https://issues.apache.org/jira/browse/SOLR-16263 
 , "Migrate tests from 
>>

Re: Cleaning up IntelliJ warnings in code base

[Eric Pugh]

While sitting in the car from Virginia to Missouri I have been fixing up
typos and grammar.

https://github.com/apache/solr/pull/900

Tomorrow on the way to Kansas I will finish up the last few tests.

I would love to get some review   my thought is if any of the changes I
made don’t seem right I will back them out.  Erik Hatcher gave me one
example, the use of the word collocated versus colated.

 I would love to merge this on Tuesday on my way to Colorado.

On Thu, Jun 9, 2022 at 4:40 PM Eric Pugh 
wrote:

> Thanks Mike for fixing my backport issue……
>
> So, I’ve wended my way through 84 files focusing on grammar and typos:
> https://github.com/apache/solr/pull/900
>
> One thing I wanted to highlight, the AffinityPlacementFactory.java
> 
>  has
> a typo in the Exception message.   I fixed it, but wondered if there was
> potentially some small chance that the original spelling is important for
> some reason?
>
> I’d love a thumbs up that I’m going in the right direction, I’ll probably
> pick this up again on Saturday….
>
>
> Eric
>
>
> On Jun 3, 2022, at 4:52 PM, Eric Pugh 
> wrote:
>
> Okay, I merged the other day….
>
> Firstly, in terms of a workflow, I looked at the Solr-NightlyTests-main
> Jenkins test, and in fact the one that ran after my commit has two tests
> that failed that look like normal build failures….  Versus what I
> committed:
> https://ci-builds.apache.org/job/Solr/job/Solr-NightlyTests-main/445/#showFailuresLink
>
> Are there any other Jenkin’s builds I should keep an eye on?
>
> Secondly, what is the Jenkins Test Failure Report that I should keep an
> eye on?  I’ve seen
> http://fucit.org/solr-jenkins-reports/failure-report.html in the past,
> and is this the one we want?   It looks like this report aggregates from
> MANY different Jenkins jobs, so I would be looking for a failure that
> starts up post my commit?   Or, do you recommend that I focus on
> http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html
> ??/
>
> Lastly, give it say 5 days and then back port to branch_9x???
>
> Thanks!
>
> Eric
>
>
>
> On Jun 1, 2022, at 8:11 AM, Eric Pugh 
> wrote:
>
> One last question….  “Squash and Merge” right?  We don’t care about all my
> interim commits….
>
> On May 31, 2022, at 6:37 PM, Eric Pugh 
> wrote:
>
> Cool.
>
> So here is an example of what I’ll merge in a day or so:
> https://github.com/apache/solr/pull/885
>
> And I’m going to start on a new PR for
> https://issues.apache.org/jira/browse/SOLR-16224 that is about looking at
> how fields are defined in the tests.
>
>
>
> On May 31, 2022, at 12:41 PM, Houston Putman  wrote:
>
> What about back porting, would you want these back ported to 8 and 9?   Or
>> just 9?
>>
>
> I would say just main and branch_9x
>
> On Tue, May 31, 2022 at 12:39 PM Eric Pugh <
> ep...@opensourceconnections.com> wrote:
>
>> Thanks for the response Mike…
>>
>> So I finished up going through the test code, and yeah, wow….  Doing it
>> one file at a time was educational at least ;-).
>>
>>
>> https://github.com/apache/solr/compare/main...epugh:intellij_inspired_cleanups?expand=1
>>
>> In terms of a workflow, should I open up a single JIRA and then list
>> under it a task for each type of fix?  And then merge each individual type
>> of fix?
>>
>> So a single JIRA issue “Examine IntelliJ Warnings in Test Code”, and then
>> a JIRA under that for each type, starting with “Remove Exceptions not
>> thrown by Method”?   Then merge each one to main, wait a few days to make
>> sure no spike in errors, and then do the next one?
>>
>> What about back porting, would you want these back ported to 8 and 9?
>> Or just 9?
>>
>>
>>
>> Eric
>>
>> On May 27, 2022, at 8:50 PM, Mike Drob  wrote:
>>
>> Declaring an unused thrown exception in tests isn't the most critical
>> change, but cleaning this up might help us discover accidental API
>> signature changes in the future. If a test throws an exception then JUnit
>> will figure it out and fail the test anyway, which is probably what we want
>> to do regardless.
>>
>> I'm +0 on this, like I am not going to go out of my way to refactor that,
>> but now that you've done it I don't want to just throw away your work so
>> it's probably fine to commit. I hope this was some automated fix you could
>> apply instead of doing manually.
>> But I'm also not going to review it, so I hope you trust the automated
>> tooling and are willing to volunteer watching Jenkins for a few days after.
>> :)
>>
>> Unused exceptions anywhere under src/main I would be _very_ interested
>> in, on the other hand.
>>
>> Mike
>>
>> On Fri, May 27, 2022 at 7:33 PM Eric Pugh <
>> ep...@opensourceconnections.com> wrote:
>>
>>> So, going through and cleaning up unused throwing of exceptions, I’ve
>>> touched all these files listed below.   I was thinking I would do ONE
>>> commit for all of the “remove unused Exception”….   B

Re: Cleaning up IntelliJ warnings in code base

[Eric Pugh]

Thanks Mike for fixing my backport issue……

So, I’ve wended my way through 84 files focusing on grammar and typos: 
https://github.com/apache/solr/pull/900

One thing I wanted to highlight, the AffinityPlacementFactory.java 

 has a typo in the Exception message.   I fixed it, but wondered if there was 
potentially some small chance that the original spelling is important for some 
reason?

I’d love a thumbs up that I’m going in the right direction, I’ll probably pick 
this up again on Saturday….


Eric
 
> On Jun 3, 2022, at 4:52 PM, Eric Pugh  wrote:
> 
> Okay, I merged the other day…. 
> 
> Firstly, in terms of a workflow, I looked at the Solr-NightlyTests-main 
> Jenkins test, and in fact the one that ran after my commit has two tests that 
> failed that look like normal build failures….  Versus what I committed: 
> https://ci-builds.apache.org/job/Solr/job/Solr-NightlyTests-main/445/#showFailuresLink
>  
> 
> 
> Are there any other Jenkin’s builds I should keep an eye on?
> 
> Secondly, what is the Jenkins Test Failure Report that I should keep an eye 
> on?  I’ve seen http://fucit.org/solr-jenkins-reports/failure-report.html 
>  in the past, and 
> is this the one we want?   It looks like this report aggregates from MANY 
> different Jenkins jobs, so I would be looking for a failure that starts up 
> post my commit?   Or, do you recommend that I focus on 
> http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html 
>  
> ??/
> 
> Lastly, give it say 5 days and then back port to branch_9x???
> 
> Thanks!
> 
> Eric
> 
> 
> 
>> On Jun 1, 2022, at 8:11 AM, Eric Pugh > > wrote:
>> 
>> One last question….  “Squash and Merge” right?  We don’t care about all my 
>> interim commits….  
>> 
>>> On May 31, 2022, at 6:37 PM, Eric Pugh >> > wrote:
>>> 
>>> Cool.  
>>> 
>>> So here is an example of what I’ll merge in a day or so: 
>>> https://github.com/apache/solr/pull/885 
>>> 
>>> 
>>> And I’m going to start on a new PR for 
>>> https://issues.apache.org/jira/browse/SOLR-16224 
>>>  that is about looking at 
>>> how fields are defined in the tests.
>>> 
>>> 
>>> 
 On May 31, 2022, at 12:41 PM, Houston Putman >>> > wrote:
 
 What about back porting, would you want these back ported to 8 and 9?   Or 
 just 9?
 
 I would say just main and branch_9x 
 
 On Tue, May 31, 2022 at 12:39 PM Eric Pugh 
 mailto:ep...@opensourceconnections.com>> 
 wrote:
 Thanks for the response Mike…
 
 So I finished up going through the test code, and yeah, wow….  Doing it 
 one file at a time was educational at least ;-).
 
 https://github.com/apache/solr/compare/main...epugh:intellij_inspired_cleanups?expand=1
  
 
 
 In terms of a workflow, should I open up a single JIRA and then list under 
 it a task for each type of fix?  And then merge each individual type of 
 fix?  
 
 So a single JIRA issue “Examine IntelliJ Warnings in Test Code”, and then 
 a JIRA under that for each type, starting with “Remove Exceptions not 
 thrown by Method”?   Then merge each one to main, wait a few days to make 
 sure no spike in errors, and then do the next one?
 
 What about back porting, would you want these back ported to 8 and 9?   Or 
 just 9?
 
 
 
 Eric
 
> On May 27, 2022, at 8:50 PM, Mike Drob  > wrote:
> 
> Declaring an unused thrown exception in tests isn't the most critical 
> change, but cleaning this up might help us discover accidental API 
> signature changes in the future. If a test throws an exception then JUnit 
> will figure it out and fail the test anyway, which is probably what we 
> want to do regardless.
> 
> I'm +0 on this, like I am not going to go out of my way to refactor that, 
> but now that you've done it I don't want to just throw away your work so 
> it's probably fine to commit. I hope this was some automated fix you 
> could apply instead of doing manually.
> But I'm also not going to review it, so I hope you trust the automated 
> tooling and are willing to volunteer watching Jenkins for a few days 
> after. :)
> 
> Unused exceptions anywhere under src/main I would be _very_ interested 
> in, on the other hand.
> 
> Mike
> 

Re: Cleaning up IntelliJ warnings in code base

[Eric Pugh]

Okay, I merged the other day…. 

Firstly, in terms of a workflow, I looked at the Solr-NightlyTests-main Jenkins 
test, and in fact the one that ran after my commit has two tests that failed 
that look like normal build failures….  Versus what I committed: 
https://ci-builds.apache.org/job/Solr/job/Solr-NightlyTests-main/445/#showFailuresLink

Are there any other Jenkin’s builds I should keep an eye on?

Secondly, what is the Jenkins Test Failure Report that I should keep an eye on? 
 I’ve seen http://fucit.org/solr-jenkins-reports/failure-report.html in the 
past, and is this the one we want?   It looks like this report aggregates from 
MANY different Jenkins jobs, so I would be looking for a failure that starts up 
post my commit?   Or, do you recommend that I focus on 
http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html ??/

Lastly, give it say 5 days and then back port to branch_9x???

Thanks!

Eric



> On Jun 1, 2022, at 8:11 AM, Eric Pugh  wrote:
> 
> One last question….  “Squash and Merge” right?  We don’t care about all my 
> interim commits….  
> 
>> On May 31, 2022, at 6:37 PM, Eric Pugh > > wrote:
>> 
>> Cool.  
>> 
>> So here is an example of what I’ll merge in a day or so: 
>> https://github.com/apache/solr/pull/885 
>> 
>> 
>> And I’m going to start on a new PR for 
>> https://issues.apache.org/jira/browse/SOLR-16224 
>>  that is about looking at 
>> how fields are defined in the tests.
>> 
>> 
>> 
>>> On May 31, 2022, at 12:41 PM, Houston Putman >> > wrote:
>>> 
>>> What about back porting, would you want these back ported to 8 and 9?   Or 
>>> just 9?
>>> 
>>> I would say just main and branch_9x 
>>> 
>>> On Tue, May 31, 2022 at 12:39 PM Eric Pugh >> > wrote:
>>> Thanks for the response Mike…
>>> 
>>> So I finished up going through the test code, and yeah, wow….  Doing it one 
>>> file at a time was educational at least ;-).
>>> 
>>> https://github.com/apache/solr/compare/main...epugh:intellij_inspired_cleanups?expand=1
>>>  
>>> 
>>> 
>>> In terms of a workflow, should I open up a single JIRA and then list under 
>>> it a task for each type of fix?  And then merge each individual type of 
>>> fix?  
>>> 
>>> So a single JIRA issue “Examine IntelliJ Warnings in Test Code”, and then a 
>>> JIRA under that for each type, starting with “Remove Exceptions not thrown 
>>> by Method”?   Then merge each one to main, wait a few days to make sure no 
>>> spike in errors, and then do the next one?
>>> 
>>> What about back porting, would you want these back ported to 8 and 9?   Or 
>>> just 9?
>>> 
>>> 
>>> 
>>> Eric
>>> 
 On May 27, 2022, at 8:50 PM, Mike Drob >>> > wrote:
 
 Declaring an unused thrown exception in tests isn't the most critical 
 change, but cleaning this up might help us discover accidental API 
 signature changes in the future. If a test throws an exception then JUnit 
 will figure it out and fail the test anyway, which is probably what we 
 want to do regardless.
 
 I'm +0 on this, like I am not going to go out of my way to refactor that, 
 but now that you've done it I don't want to just throw away your work so 
 it's probably fine to commit. I hope this was some automated fix you could 
 apply instead of doing manually.
 But I'm also not going to review it, so I hope you trust the automated 
 tooling and are willing to volunteer watching Jenkins for a few days 
 after. :)
 
 Unused exceptions anywhere under src/main I would be _very_ interested in, 
 on the other hand.
 
 Mike
 
 On Fri, May 27, 2022 at 7:33 PM Eric Pugh >>> > wrote:
 So, going through and cleaning up unused throwing of exceptions, I’ve 
 touched all these files listed below.   I was thinking I would do ONE 
 commit for all of the “remove unused Exception”….   Before I keep going, 
 wanted to make sure that makes sense…..   
 
modified:   
 solr/core/src/test/org/apache/solr/analysis/CommonGramsPhraseQueryTest.java
modified:   
 solr/core/src/test/org/apache/solr/analysis/PathHierarchyTokenizerFactoryTest.java
modified:   
 solr/core/src/test/org/apache/solr/analysis/TestLuceneMatchVersion.java
modified:   
 solr/core/src/test/org/apache/solr/analysis/TestReversedWildcardFilterFactory.java
modified:   
 solr/core/src/test/org/apache/solr/analysis/TokenizerChainTest.java
modified:   
 solr/core/src/test/org/apache/solr/cloud/ActionThrottleTest.java
modified:   
 solr/core/src/test/org/apache/solr/cloud/AssignBackwardCompatibilityTest.java
modif

Re: Cleaning up IntelliJ warnings in code base

[Jason Gerlowski]

+1 to "Squash and Merge"

On Wed, Jun 1, 2022 at 10:00 AM Houston Putman  wrote:

> 100%, in my opinion
>
> On Wed, Jun 1, 2022 at 8:11 AM Eric Pugh 
> wrote:
>
>> One last question….  “Squash and Merge” right?  We don’t care about all
>> my interim commits….
>>
>>
>> On May 31, 2022, at 6:37 PM, Eric Pugh 
>> wrote:
>>
>> Cool.
>>
>> So here is an example of what I’ll merge in a day or so:
>> https://github.com/apache/solr/pull/885
>>
>> And I’m going to start on a new PR for
>> https://issues.apache.org/jira/browse/SOLR-16224 that is about looking
>> at how fields are defined in the tests.
>>
>>
>>
>> On May 31, 2022, at 12:41 PM, Houston Putman  wrote:
>>
>> What about back porting, would you want these back ported to 8 and 9?
>>> Or just 9?
>>>
>>
>> I would say just main and branch_9x
>>
>> On Tue, May 31, 2022 at 12:39 PM Eric Pugh <
>> ep...@opensourceconnections.com> wrote:
>>
>>> Thanks for the response Mike…
>>>
>>> So I finished up going through the test code, and yeah, wow….  Doing it
>>> one file at a time was educational at least ;-).
>>>
>>>
>>> https://github.com/apache/solr/compare/main...epugh:intellij_inspired_cleanups?expand=1
>>>
>>> In terms of a workflow, should I open up a single JIRA and then list
>>> under it a task for each type of fix?  And then merge each individual type
>>> of fix?
>>>
>>> So a single JIRA issue “Examine IntelliJ Warnings in Test Code”, and
>>> then a JIRA under that for each type, starting with “Remove Exceptions not
>>> thrown by Method”?   Then merge each one to main, wait a few days to make
>>> sure no spike in errors, and then do the next one?
>>>
>>> What about back porting, would you want these back ported to 8 and 9?
>>> Or just 9?
>>>
>>>
>>>
>>> Eric
>>>
>>> On May 27, 2022, at 8:50 PM, Mike Drob  wrote:
>>>
>>> Declaring an unused thrown exception in tests isn't the most critical
>>> change, but cleaning this up might help us discover accidental API
>>> signature changes in the future. If a test throws an exception then JUnit
>>> will figure it out and fail the test anyway, which is probably what we want
>>> to do regardless.
>>>
>>> I'm +0 on this, like I am not going to go out of my way to refactor
>>> that, but now that you've done it I don't want to just throw away your work
>>> so it's probably fine to commit. I hope this was some automated fix
>>> you could apply instead of doing manually.
>>> But I'm also not going to review it, so I hope you trust the automated
>>> tooling and are willing to volunteer watching Jenkins for a few days after.
>>> :)
>>>
>>> Unused exceptions anywhere under src/main I would be _very_ interested
>>> in, on the other hand.
>>>
>>> Mike
>>>
>>> On Fri, May 27, 2022 at 7:33 PM Eric Pugh <
>>> ep...@opensourceconnections.com> wrote:
>>>
 So, going through and cleaning up unused throwing of exceptions, I’ve
 touched all these files listed below.   I was thinking I would do ONE
 commit for all of the “remove unused Exception”….   Before I keep going,
 wanted to make sure that makes sense…..

 modified:
 solr/core/src/test/org/apache/solr/analysis/CommonGramsPhraseQueryTest.java
 modified:
 solr/core/src/test/org/apache/solr/analysis/PathHierarchyTokenizerFactoryTest.java
 modified:
 solr/core/src/test/org/apache/solr/analysis/TestLuceneMatchVersion.java
 modified:
 solr/core/src/test/org/apache/solr/analysis/TestReversedWildcardFilterFactory.java
 modified:
 solr/core/src/test/org/apache/solr/analysis/TokenizerChainTest.java
 modified:
 solr/core/src/test/org/apache/solr/cloud/ActionThrottleTest.java
 modified:
 solr/core/src/test/org/apache/solr/cloud/AssignBackwardCompatibilityTest.java
 modified:
 solr/core/src/test/org/apache/solr/cloud/ChaosMonkeyShardSplitTest.java
 modified:
 solr/core/src/test/org/apache/solr/cloud/CollectionPropsTest.java
 modified:
 solr/core/src/test/org/apache/solr/cloud/CollectionsAPISolrJTest.java
 modified:
 solr/core/src/test/org/apache/solr/cloud/ConcurrentCreateRoutedAliasTest.java
 modified:
 solr/core/src/test/org/apache/solr/cloud/ConfigSetApiLockingTest.java
 modified:
 solr/core/src/test/org/apache/solr/cloud/CreateRoutedAliasTest.java
 modified:
 solr/core/src/test/org/apache/solr/cloud/DeleteShardTest.java
 modified:
 solr/core/src/test/org/apache/solr/cloud/DistribJoinFromCollectionTest.java
 modified:
 solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
 modified:
 solr/core/src/test/org/apache/solr/cloud/HttpPartitionTest.java
 modified:
 solr/core/src/test/org/apache/solr/cloud/LeaderElectionTest.java
 modified:   solr/core/src/test/org/apache/solr/cloud/OverseerTest.java
 modified:
 solr/core/src/test/org/apache/solr/cloud/ReindexCollectionTest.java
 modified:
 solr/core/src/test/org/apache/solr/cloud/SSLMigrationTest.java
 modified:
 solr/core/src/test/org/apache/solr/cloud

Re: Cleaning up IntelliJ warnings in code base

[Houston Putman]

100%, in my opinion

On Wed, Jun 1, 2022 at 8:11 AM Eric Pugh 
wrote:

> One last question….  “Squash and Merge” right?  We don’t care about all my
> interim commits….
>
>
> On May 31, 2022, at 6:37 PM, Eric Pugh 
> wrote:
>
> Cool.
>
> So here is an example of what I’ll merge in a day or so:
> https://github.com/apache/solr/pull/885
>
> And I’m going to start on a new PR for
> https://issues.apache.org/jira/browse/SOLR-16224 that is about looking at
> how fields are defined in the tests.
>
>
>
> On May 31, 2022, at 12:41 PM, Houston Putman  wrote:
>
> What about back porting, would you want these back ported to 8 and 9?   Or
>> just 9?
>>
>
> I would say just main and branch_9x
>
> On Tue, May 31, 2022 at 12:39 PM Eric Pugh <
> ep...@opensourceconnections.com> wrote:
>
>> Thanks for the response Mike…
>>
>> So I finished up going through the test code, and yeah, wow….  Doing it
>> one file at a time was educational at least ;-).
>>
>>
>> https://github.com/apache/solr/compare/main...epugh:intellij_inspired_cleanups?expand=1
>>
>> In terms of a workflow, should I open up a single JIRA and then list
>> under it a task for each type of fix?  And then merge each individual type
>> of fix?
>>
>> So a single JIRA issue “Examine IntelliJ Warnings in Test Code”, and then
>> a JIRA under that for each type, starting with “Remove Exceptions not
>> thrown by Method”?   Then merge each one to main, wait a few days to make
>> sure no spike in errors, and then do the next one?
>>
>> What about back porting, would you want these back ported to 8 and 9?
>> Or just 9?
>>
>>
>>
>> Eric
>>
>> On May 27, 2022, at 8:50 PM, Mike Drob  wrote:
>>
>> Declaring an unused thrown exception in tests isn't the most critical
>> change, but cleaning this up might help us discover accidental API
>> signature changes in the future. If a test throws an exception then JUnit
>> will figure it out and fail the test anyway, which is probably what we want
>> to do regardless.
>>
>> I'm +0 on this, like I am not going to go out of my way to refactor that,
>> but now that you've done it I don't want to just throw away your work so
>> it's probably fine to commit. I hope this was some automated fix you could
>> apply instead of doing manually.
>> But I'm also not going to review it, so I hope you trust the automated
>> tooling and are willing to volunteer watching Jenkins for a few days after.
>> :)
>>
>> Unused exceptions anywhere under src/main I would be _very_ interested
>> in, on the other hand.
>>
>> Mike
>>
>> On Fri, May 27, 2022 at 7:33 PM Eric Pugh <
>> ep...@opensourceconnections.com> wrote:
>>
>>> So, going through and cleaning up unused throwing of exceptions, I’ve
>>> touched all these files listed below.   I was thinking I would do ONE
>>> commit for all of the “remove unused Exception”….   Before I keep going,
>>> wanted to make sure that makes sense…..
>>>
>>> modified:
>>> solr/core/src/test/org/apache/solr/analysis/CommonGramsPhraseQueryTest.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/analysis/PathHierarchyTokenizerFactoryTest.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/analysis/TestLuceneMatchVersion.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/analysis/TestReversedWildcardFilterFactory.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/analysis/TokenizerChainTest.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/cloud/ActionThrottleTest.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/cloud/AssignBackwardCompatibilityTest.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/cloud/ChaosMonkeyShardSplitTest.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/cloud/CollectionPropsTest.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/cloud/CollectionsAPISolrJTest.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/cloud/ConcurrentCreateRoutedAliasTest.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/cloud/ConfigSetApiLockingTest.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/cloud/CreateRoutedAliasTest.java
>>> modified:   solr/core/src/test/org/apache/solr/cloud/DeleteShardTest.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/cloud/DistribJoinFromCollectionTest.java
>>> modified:   solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/cloud/HttpPartitionTest.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/cloud/LeaderElectionTest.java
>>> modified:   solr/core/src/test/org/apache/solr/cloud/OverseerTest.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/cloud/ReindexCollectionTest.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/cloud/SSLMigrationTest.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/cloud/SolrCLIZkUtilsTest.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/cloud/TestAuthenticationFramework.java
>>> modified:
>>> solr/core/src/test/org/apache/solr/cloud/TestBaseStatsCacheCloud.java
>>> modified

Re: Cleaning up IntelliJ warnings in code base

[Eric Pugh]

One last question….  “Squash and Merge” right?  We don’t care about all my 
interim commits….  

> On May 31, 2022, at 6:37 PM, Eric Pugh  
> wrote:
> 
> Cool.  
> 
> So here is an example of what I’ll merge in a day or so: 
> https://github.com/apache/solr/pull/885 
> 
> 
> And I’m going to start on a new PR for 
> https://issues.apache.org/jira/browse/SOLR-16224 
>  that is about looking at 
> how fields are defined in the tests.
> 
> 
> 
>> On May 31, 2022, at 12:41 PM, Houston Putman > > wrote:
>> 
>> What about back porting, would you want these back ported to 8 and 9?   Or 
>> just 9?
>> 
>> I would say just main and branch_9x 
>> 
>> On Tue, May 31, 2022 at 12:39 PM Eric Pugh > > wrote:
>> Thanks for the response Mike…
>> 
>> So I finished up going through the test code, and yeah, wow….  Doing it one 
>> file at a time was educational at least ;-).
>> 
>> https://github.com/apache/solr/compare/main...epugh:intellij_inspired_cleanups?expand=1
>>  
>> 
>> 
>> In terms of a workflow, should I open up a single JIRA and then list under 
>> it a task for each type of fix?  And then merge each individual type of fix? 
>>  
>> 
>> So a single JIRA issue “Examine IntelliJ Warnings in Test Code”, and then a 
>> JIRA under that for each type, starting with “Remove Exceptions not thrown 
>> by Method”?   Then merge each one to main, wait a few days to make sure no 
>> spike in errors, and then do the next one?
>> 
>> What about back porting, would you want these back ported to 8 and 9?   Or 
>> just 9?
>> 
>> 
>> 
>> Eric
>> 
>>> On May 27, 2022, at 8:50 PM, Mike Drob >> > wrote:
>>> 
>>> Declaring an unused thrown exception in tests isn't the most critical 
>>> change, but cleaning this up might help us discover accidental API 
>>> signature changes in the future. If a test throws an exception then JUnit 
>>> will figure it out and fail the test anyway, which is probably what we want 
>>> to do regardless.
>>> 
>>> I'm +0 on this, like I am not going to go out of my way to refactor that, 
>>> but now that you've done it I don't want to just throw away your work so 
>>> it's probably fine to commit. I hope this was some automated fix you could 
>>> apply instead of doing manually.
>>> But I'm also not going to review it, so I hope you trust the automated 
>>> tooling and are willing to volunteer watching Jenkins for a few days after. 
>>> :)
>>> 
>>> Unused exceptions anywhere under src/main I would be _very_ interested in, 
>>> on the other hand.
>>> 
>>> Mike
>>> 
>>> On Fri, May 27, 2022 at 7:33 PM Eric Pugh >> > wrote:
>>> So, going through and cleaning up unused throwing of exceptions, I’ve 
>>> touched all these files listed below.   I was thinking I would do ONE 
>>> commit for all of the “remove unused Exception”….   Before I keep going, 
>>> wanted to make sure that makes sense…..   
>>> 
>>> modified:   
>>> solr/core/src/test/org/apache/solr/analysis/CommonGramsPhraseQueryTest.java
>>> modified:   
>>> solr/core/src/test/org/apache/solr/analysis/PathHierarchyTokenizerFactoryTest.java
>>> modified:   
>>> solr/core/src/test/org/apache/solr/analysis/TestLuceneMatchVersion.java
>>> modified:   
>>> solr/core/src/test/org/apache/solr/analysis/TestReversedWildcardFilterFactory.java
>>> modified:   
>>> solr/core/src/test/org/apache/solr/analysis/TokenizerChainTest.java
>>> modified:   
>>> solr/core/src/test/org/apache/solr/cloud/ActionThrottleTest.java
>>> modified:   
>>> solr/core/src/test/org/apache/solr/cloud/AssignBackwardCompatibilityTest.java
>>> modified:   
>>> solr/core/src/test/org/apache/solr/cloud/ChaosMonkeyShardSplitTest.java
>>> modified:   
>>> solr/core/src/test/org/apache/solr/cloud/CollectionPropsTest.java
>>> modified:   
>>> solr/core/src/test/org/apache/solr/cloud/CollectionsAPISolrJTest.java
>>> modified:   
>>> solr/core/src/test/org/apache/solr/cloud/ConcurrentCreateRoutedAliasTest.java
>>> modified:   
>>> solr/core/src/test/org/apache/solr/cloud/ConfigSetApiLockingTest.java
>>> modified:   
>>> solr/core/src/test/org/apache/solr/cloud/CreateRoutedAliasTest.java
>>> modified:   
>>> solr/core/src/test/org/apache/solr/cloud/DeleteShardTest.java
>>> modified:   
>>> solr/core/src/test/org/apache/solr/cloud/DistribJoinFromCollectionTest.java
>>> modified:   
>>> solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
>>> modified:   
>>> solr/core/src/test/org/apache/solr/cloud/HttpPartitionTest.java
>>> modified:   
>>> solr/core/src/test/org/apache/solr/cloud/LeaderElectionTest.java
>>> modified:   solr/core/src/test/org/apache/solr/cloud/OverseerTest.java
>>> modified:   
>>> solr/core/sr

Re: Cleaning up IntelliJ warnings in code base

[Eric Pugh]

Cool.  

So here is an example of what I’ll merge in a day or so: 
https://github.com/apache/solr/pull/885

And I’m going to start on a new PR for 
https://issues.apache.org/jira/browse/SOLR-16224 that is about looking at how 
fields are defined in the tests.



> On May 31, 2022, at 12:41 PM, Houston Putman  wrote:
> 
> What about back porting, would you want these back ported to 8 and 9?   Or 
> just 9?
> 
> I would say just main and branch_9x 
> 
> On Tue, May 31, 2022 at 12:39 PM Eric Pugh  > wrote:
> Thanks for the response Mike…
> 
> So I finished up going through the test code, and yeah, wow….  Doing it one 
> file at a time was educational at least ;-).
> 
> https://github.com/apache/solr/compare/main...epugh:intellij_inspired_cleanups?expand=1
>  
> 
> 
> In terms of a workflow, should I open up a single JIRA and then list under it 
> a task for each type of fix?  And then merge each individual type of fix?  
> 
> So a single JIRA issue “Examine IntelliJ Warnings in Test Code”, and then a 
> JIRA under that for each type, starting with “Remove Exceptions not thrown by 
> Method”?   Then merge each one to main, wait a few days to make sure no spike 
> in errors, and then do the next one?
> 
> What about back porting, would you want these back ported to 8 and 9?   Or 
> just 9?
> 
> 
> 
> Eric
> 
>> On May 27, 2022, at 8:50 PM, Mike Drob > > wrote:
>> 
>> Declaring an unused thrown exception in tests isn't the most critical 
>> change, but cleaning this up might help us discover accidental API signature 
>> changes in the future. If a test throws an exception then JUnit will figure 
>> it out and fail the test anyway, which is probably what we want to do 
>> regardless.
>> 
>> I'm +0 on this, like I am not going to go out of my way to refactor that, 
>> but now that you've done it I don't want to just throw away your work so 
>> it's probably fine to commit. I hope this was some automated fix you could 
>> apply instead of doing manually.
>> But I'm also not going to review it, so I hope you trust the automated 
>> tooling and are willing to volunteer watching Jenkins for a few days after. 
>> :)
>> 
>> Unused exceptions anywhere under src/main I would be _very_ interested in, 
>> on the other hand.
>> 
>> Mike
>> 
>> On Fri, May 27, 2022 at 7:33 PM Eric Pugh > > wrote:
>> So, going through and cleaning up unused throwing of exceptions, I’ve 
>> touched all these files listed below.   I was thinking I would do ONE commit 
>> for all of the “remove unused Exception”….   Before I keep going, wanted to 
>> make sure that makes sense…..   
>> 
>>  modified:   
>> solr/core/src/test/org/apache/solr/analysis/CommonGramsPhraseQueryTest.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/analysis/PathHierarchyTokenizerFactoryTest.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/analysis/TestLuceneMatchVersion.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/analysis/TestReversedWildcardFilterFactory.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/analysis/TokenizerChainTest.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/cloud/ActionThrottleTest.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/cloud/AssignBackwardCompatibilityTest.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/cloud/ChaosMonkeyShardSplitTest.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/cloud/CollectionPropsTest.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/cloud/CollectionsAPISolrJTest.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/cloud/ConcurrentCreateRoutedAliasTest.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/cloud/ConfigSetApiLockingTest.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/cloud/CreateRoutedAliasTest.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/cloud/DeleteShardTest.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/cloud/DistribJoinFromCollectionTest.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/cloud/HttpPartitionTest.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/cloud/LeaderElectionTest.java
>>  modified:   solr/core/src/test/org/apache/solr/cloud/OverseerTest.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/cloud/ReindexCollectionTest.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/cloud/SSLMigrationTest.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/cloud/SolrCLIZkUtilsTest.java
>>  modified:   
>> solr/core/src/test/org/apache/solr/cloud/TestAuthenticationFramework.java
>>  modified:   
>> solr/core/src/test/org/apache/solr

Re: Cleaning up IntelliJ warnings in code base

[Houston Putman]

>
> What about back porting, would you want these back ported to 8 and 9?   Or
> just 9?
>

I would say just main and branch_9x

On Tue, May 31, 2022 at 12:39 PM Eric Pugh 
wrote:

> Thanks for the response Mike…
>
> So I finished up going through the test code, and yeah, wow….  Doing it
> one file at a time was educational at least ;-).
>
>
> https://github.com/apache/solr/compare/main...epugh:intellij_inspired_cleanups?expand=1
>
> In terms of a workflow, should I open up a single JIRA and then list under
> it a task for each type of fix?  And then merge each individual type of
> fix?
>
> So a single JIRA issue “Examine IntelliJ Warnings in Test Code”, and then
> a JIRA under that for each type, starting with “Remove Exceptions not
> thrown by Method”?   Then merge each one to main, wait a few days to make
> sure no spike in errors, and then do the next one?
>
> What about back porting, would you want these back ported to 8 and 9?   Or
> just 9?
>
>
>
> Eric
>
> On May 27, 2022, at 8:50 PM, Mike Drob  wrote:
>
> Declaring an unused thrown exception in tests isn't the most critical
> change, but cleaning this up might help us discover accidental API
> signature changes in the future. If a test throws an exception then JUnit
> will figure it out and fail the test anyway, which is probably what we want
> to do regardless.
>
> I'm +0 on this, like I am not going to go out of my way to refactor that,
> but now that you've done it I don't want to just throw away your work so
> it's probably fine to commit. I hope this was some automated fix you could
> apply instead of doing manually.
> But I'm also not going to review it, so I hope you trust the automated
> tooling and are willing to volunteer watching Jenkins for a few days after.
> :)
>
> Unused exceptions anywhere under src/main I would be _very_ interested in,
> on the other hand.
>
> Mike
>
> On Fri, May 27, 2022 at 7:33 PM Eric Pugh 
> wrote:
>
>> So, going through and cleaning up unused throwing of exceptions, I’ve
>> touched all these files listed below.   I was thinking I would do ONE
>> commit for all of the “remove unused Exception”….   Before I keep going,
>> wanted to make sure that makes sense…..
>>
>> modified:
>> solr/core/src/test/org/apache/solr/analysis/CommonGramsPhraseQueryTest.java
>> modified:
>> solr/core/src/test/org/apache/solr/analysis/PathHierarchyTokenizerFactoryTest.java
>> modified:
>> solr/core/src/test/org/apache/solr/analysis/TestLuceneMatchVersion.java
>> modified:
>> solr/core/src/test/org/apache/solr/analysis/TestReversedWildcardFilterFactory.java
>> modified:
>> solr/core/src/test/org/apache/solr/analysis/TokenizerChainTest.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/ActionThrottleTest.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/AssignBackwardCompatibilityTest.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/ChaosMonkeyShardSplitTest.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/CollectionPropsTest.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/CollectionsAPISolrJTest.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/ConcurrentCreateRoutedAliasTest.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/ConfigSetApiLockingTest.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/CreateRoutedAliasTest.java
>> modified:   solr/core/src/test/org/apache/solr/cloud/DeleteShardTest.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/DistribJoinFromCollectionTest.java
>> modified:   solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/HttpPartitionTest.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/LeaderElectionTest.java
>> modified:   solr/core/src/test/org/apache/solr/cloud/OverseerTest.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/ReindexCollectionTest.java
>> modified:   solr/core/src/test/org/apache/solr/cloud/SSLMigrationTest.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/SolrCLIZkUtilsTest.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/TestAuthenticationFramework.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/TestBaseStatsCacheCloud.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/TestCloudDeleteByQuery.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/TestCloudInspectUtil.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/TestCloudPivotFacet.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/TestHashPartitioner.java
>> modified:   solr/core/src/test/org/apache/solr/cloud/TestPrepRecovery.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/TestRebalanceLeaders.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/TestSSLRandomization.java
>> modified:
>> solr/core/src/test/org/apache/solr/cloud/TestStressCloudBlindAtomicUpdates.java
>> modified:   solr/core/src/test/org/apache/solr/cloud/TestTlogReplica

Re: Cleaning up IntelliJ warnings in code base

[Eric Pugh]

Thanks for the response Mike…

So I finished up going through the test code, and yeah, wow….  Doing it one 
file at a time was educational at least ;-).

https://github.com/apache/solr/compare/main...epugh:intellij_inspired_cleanups?expand=1

In terms of a workflow, should I open up a single JIRA and then list under it a 
task for each type of fix?  And then merge each individual type of fix?  

So a single JIRA issue “Examine IntelliJ Warnings in Test Code”, and then a 
JIRA under that for each type, starting with “Remove Exceptions not thrown by 
Method”?   Then merge each one to main, wait a few days to make sure no spike 
in errors, and then do the next one?

What about back porting, would you want these back ported to 8 and 9?   Or just 
9?



Eric

> On May 27, 2022, at 8:50 PM, Mike Drob  wrote:
> 
> Declaring an unused thrown exception in tests isn't the most critical change, 
> but cleaning this up might help us discover accidental API signature changes 
> in the future. If a test throws an exception then JUnit will figure it out 
> and fail the test anyway, which is probably what we want to do regardless.
> 
> I'm +0 on this, like I am not going to go out of my way to refactor that, but 
> now that you've done it I don't want to just throw away your work so it's 
> probably fine to commit. I hope this was some automated fix you could apply 
> instead of doing manually.
> But I'm also not going to review it, so I hope you trust the automated 
> tooling and are willing to volunteer watching Jenkins for a few days after. :)
> 
> Unused exceptions anywhere under src/main I would be _very_ interested in, on 
> the other hand.
> 
> Mike
> 
> On Fri, May 27, 2022 at 7:33 PM Eric Pugh  > wrote:
> So, going through and cleaning up unused throwing of exceptions, I’ve touched 
> all these files listed below.   I was thinking I would do ONE commit for all 
> of the “remove unused Exception”….   Before I keep going, wanted to make sure 
> that makes sense…..   
> 
>   modified:   
> solr/core/src/test/org/apache/solr/analysis/CommonGramsPhraseQueryTest.java
>   modified:   
> solr/core/src/test/org/apache/solr/analysis/PathHierarchyTokenizerFactoryTest.java
>   modified:   
> solr/core/src/test/org/apache/solr/analysis/TestLuceneMatchVersion.java
>   modified:   
> solr/core/src/test/org/apache/solr/analysis/TestReversedWildcardFilterFactory.java
>   modified:   
> solr/core/src/test/org/apache/solr/analysis/TokenizerChainTest.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/ActionThrottleTest.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/AssignBackwardCompatibilityTest.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/ChaosMonkeyShardSplitTest.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/CollectionPropsTest.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/CollectionsAPISolrJTest.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/ConcurrentCreateRoutedAliasTest.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/ConfigSetApiLockingTest.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/CreateRoutedAliasTest.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/DeleteShardTest.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/DistribJoinFromCollectionTest.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/HttpPartitionTest.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/LeaderElectionTest.java
>   modified:   solr/core/src/test/org/apache/solr/cloud/OverseerTest.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/ReindexCollectionTest.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/SSLMigrationTest.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/SolrCLIZkUtilsTest.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/TestAuthenticationFramework.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/TestBaseStatsCacheCloud.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/TestCloudDeleteByQuery.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/TestCloudInspectUtil.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/TestCloudPivotFacet.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/TestHashPartitioner.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/TestPrepRecovery.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/TestRebalanceLeaders.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/TestSSLRandomization.java
>   modified:   
> solr/core/src/test/org/apache/solr/cloud/TestStressCloudBlindAtomicUpdates.java
>   

Re: Cleaning up IntelliJ warnings in code base

[Mike Drob]

Declaring an unused thrown exception in tests isn't the most critical
change, but cleaning this up might help us discover accidental API
signature changes in the future. If a test throws an exception then JUnit
will figure it out and fail the test anyway, which is probably what we want
to do regardless.

I'm +0 on this, like I am not going to go out of my way to refactor that,
but now that you've done it I don't want to just throw away your work so
it's probably fine to commit. I hope this was some automated fix you could
apply instead of doing manually.
But I'm also not going to review it, so I hope you trust the automated
tooling and are willing to volunteer watching Jenkins for a few days after.
:)

Unused exceptions anywhere under src/main I would be _very_ interested in,
on the other hand.

Mike

On Fri, May 27, 2022 at 7:33 PM Eric Pugh 
wrote:

> So, going through and cleaning up unused throwing of exceptions, I’ve
> touched all these files listed below.   I was thinking I would do ONE
> commit for all of the “remove unused Exception”….   Before I keep going,
> wanted to make sure that makes sense…..
>
> modified:
> solr/core/src/test/org/apache/solr/analysis/CommonGramsPhraseQueryTest.java
> modified:
> solr/core/src/test/org/apache/solr/analysis/PathHierarchyTokenizerFactoryTest.java
> modified:
> solr/core/src/test/org/apache/solr/analysis/TestLuceneMatchVersion.java
> modified:
> solr/core/src/test/org/apache/solr/analysis/TestReversedWildcardFilterFactory.java
> modified:
> solr/core/src/test/org/apache/solr/analysis/TokenizerChainTest.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/ActionThrottleTest.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/AssignBackwardCompatibilityTest.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/ChaosMonkeyShardSplitTest.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/CollectionPropsTest.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/CollectionsAPISolrJTest.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/ConcurrentCreateRoutedAliasTest.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/ConfigSetApiLockingTest.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/CreateRoutedAliasTest.java
> modified:   solr/core/src/test/org/apache/solr/cloud/DeleteShardTest.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/DistribJoinFromCollectionTest.java
> modified:   solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
> modified:   solr/core/src/test/org/apache/solr/cloud/HttpPartitionTest.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/LeaderElectionTest.java
> modified:   solr/core/src/test/org/apache/solr/cloud/OverseerTest.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/ReindexCollectionTest.java
> modified:   solr/core/src/test/org/apache/solr/cloud/SSLMigrationTest.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/SolrCLIZkUtilsTest.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/TestAuthenticationFramework.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/TestBaseStatsCacheCloud.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/TestCloudDeleteByQuery.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/TestCloudInspectUtil.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/TestCloudPivotFacet.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/TestHashPartitioner.java
> modified:   solr/core/src/test/org/apache/solr/cloud/TestPrepRecovery.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/TestRebalanceLeaders.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/TestSSLRandomization.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/TestStressCloudBlindAtomicUpdates.java
> modified:   solr/core/src/test/org/apache/solr/cloud/TestTlogReplica.java
> modified:   solr/core/src/test/org/apache/solr/cloud/ZkCLITest.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/api/collections/AsyncCallRequestStatusResponseTest.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/api/collections/BackupRestoreApiErrorConditionsTest.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/api/collections/CollectionApiLockingTest.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/api/collections/CollectionTooManyReplicasTest.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/api/collections/ReplicaPropertiesBase.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/api/collections/TestLocalFSCloudBackupRestore.java
> modified:
> solr/core/src/test/org/apache/solr/cloud/api/collections/TestReplicaProperties.java
> modified:
> solr/core/src/test/org/apache/solr/cluster/events/impl/CollectionsRepairEventListenerTest.java
> modified:
> solr/core/src/test/org/apache/solr/core/AlternateDirectoryTest.java
> modified:
> solr/core/src/test/org/apache/solr/core/ConfigureRecoveryStrategyTest.java
> modified:
> solr/core/src/test/org/apache/

Re: Cleaning up IntelliJ warnings in code base

[Eric Pugh]

So, going through and cleaning up unused throwing of exceptions, I’ve touched 
all these files listed below.   I was thinking I would do ONE commit for all of 
the “remove unused Exception”….   Before I keep going, wanted to make sure that 
makes sense…..   

modified:   
solr/core/src/test/org/apache/solr/analysis/CommonGramsPhraseQueryTest.java
modified:   
solr/core/src/test/org/apache/solr/analysis/PathHierarchyTokenizerFactoryTest.java
modified:   
solr/core/src/test/org/apache/solr/analysis/TestLuceneMatchVersion.java
modified:   
solr/core/src/test/org/apache/solr/analysis/TestReversedWildcardFilterFactory.java
modified:   
solr/core/src/test/org/apache/solr/analysis/TokenizerChainTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/ActionThrottleTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/AssignBackwardCompatibilityTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/ChaosMonkeyShardSplitTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/CollectionPropsTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/CollectionsAPISolrJTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/ConcurrentCreateRoutedAliasTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/ConfigSetApiLockingTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/CreateRoutedAliasTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/DeleteShardTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/DistribJoinFromCollectionTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/HttpPartitionTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/LeaderElectionTest.java
modified:   solr/core/src/test/org/apache/solr/cloud/OverseerTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/ReindexCollectionTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/SSLMigrationTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/SolrCLIZkUtilsTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/TestAuthenticationFramework.java
modified:   
solr/core/src/test/org/apache/solr/cloud/TestBaseStatsCacheCloud.java
modified:   
solr/core/src/test/org/apache/solr/cloud/TestCloudDeleteByQuery.java
modified:   
solr/core/src/test/org/apache/solr/cloud/TestCloudInspectUtil.java
modified:   
solr/core/src/test/org/apache/solr/cloud/TestCloudPivotFacet.java
modified:   
solr/core/src/test/org/apache/solr/cloud/TestHashPartitioner.java
modified:   
solr/core/src/test/org/apache/solr/cloud/TestPrepRecovery.java
modified:   
solr/core/src/test/org/apache/solr/cloud/TestRebalanceLeaders.java
modified:   
solr/core/src/test/org/apache/solr/cloud/TestSSLRandomization.java
modified:   
solr/core/src/test/org/apache/solr/cloud/TestStressCloudBlindAtomicUpdates.java
modified:   
solr/core/src/test/org/apache/solr/cloud/TestTlogReplica.java
modified:   solr/core/src/test/org/apache/solr/cloud/ZkCLITest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/api/collections/AsyncCallRequestStatusResponseTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/api/collections/BackupRestoreApiErrorConditionsTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/api/collections/CollectionApiLockingTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/api/collections/CollectionTooManyReplicasTest.java
modified:   
solr/core/src/test/org/apache/solr/cloud/api/collections/ReplicaPropertiesBase.java
modified:   
solr/core/src/test/org/apache/solr/cloud/api/collections/TestLocalFSCloudBackupRestore.java
modified:   
solr/core/src/test/org/apache/solr/cloud/api/collections/TestReplicaProperties.java
modified:   
solr/core/src/test/org/apache/solr/cluster/events/impl/CollectionsRepairEventListenerTest.java
modified:   
solr/core/src/test/org/apache/solr/core/AlternateDirectoryTest.java
modified:   
solr/core/src/test/org/apache/solr/core/ConfigureRecoveryStrategyTest.java
modified:   
solr/core/src/test/org/apache/solr/core/DirectoryFactoryTest.java
modified:   solr/core/src/test/org/apache/solr/core/HelloStream.java
modified:   
solr/core/src/test/org/apache/solr/core/ResourceLoaderTest.java
modified:   solr/core/src/test/org/apache/solr/core/SOLR749Test.java
modified:   solr/core/src/test/org/apache/solr/core/SolrCoreTest.java
modified:   
solr/core/src/test/org/apache/solr/core/TestBackupRepositoryFactory.java
modified:   
solr/core/src/test/org/apache/solr/core/TestCodecSupport.java
modified:   solr

Re: Cleaning up IntelliJ warnings in code base

[David Smiley]

IntelliJ is produced by a company and I have no idea how they go about
selecting what the default inspections (what IntelliJ calls these) are.
Maybe it was one person there, maybe it was arbitrary by whoever wrote
the inspection, or maybe they had some more thoughtful approach that looked
at literature.  Regardless, I disagree with some of their choices.  I think
we should base our decisions on what inspections to address for ourselves,
not *just* because JetBrains included them.  I routinely adjust my IntelliJ
inspection settings to not harass me about some matters that I consider to
be frivolous.  For example boolean expression simplifications -- where we
as a project (when a part of Lucene) have chosen "== false" to be
clearer than an exclamation point adjacent to a boolean expression.

If we do some of this:  Agreed on picking exactly one "inspection" and
scoping to just one module at first.  Could increase to more commits in the
same PR if you get good feedback.
Personally, I wouldn't do this endeavor unless the particular inspection is
something that particularly motivates me / was a pet-peeve.
I think "getting to green" is a toal lost cause unless we were to enforce a
particular configured list of inspections (which is IntelliJ only,
remember).

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Fri, May 27, 2022 at 12:52 PM Shawn Heisey  wrote:

> On 5/27/2022 8:24 AM, Eric Pugh wrote:
> > Hey all, was poking around at a unit test while watching TV and
> > noticed lots of warnings from IntelliJ, little stuff like exceptions
> > being thrown that don’t need to be thrown, unused variables, or typos.
>
> In eclipse, there are THOUSANDS of warnings.  And last I checked, even a
> bunch of errors.  But I was able to build 10.0.0-SNAPSHOT successfully.
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>
>

Re: Cleaning up IntelliJ warnings in code base

[Shawn Heisey]

On 5/27/2022 8:24 AM, Eric Pugh wrote:
Hey all, was poking around at a unit test while watching TV and 
noticed lots of warnings from IntelliJ, little stuff like exceptions 
being thrown that don’t need to be thrown, unused variables, or typos.


In eclipse, there are THOUSANDS of warnings.  And last I checked, even a 
bunch of errors.  But I was able to build 10.0.0-SNAPSHOT successfully.


Thanks,
Shawn


-
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

Re: Cleaning up IntelliJ warnings in code base

[Gus Heck]

Yeah I'm certainly for cleaning up warnings, but I agree it should be in
small chunks, and considered. In some cases "cleanup" will be
//noinspection or @SuppressWarnings...

Getting to a green check mark is quite beneficial, making it easier to
notice when you've added something that's (possibly) questionable.

On Fri, May 27, 2022 at 11:26 AM Michael Gibney 
wrote:

> I have a vague recollection of having seen intellij warnings that
> really _shouldn't_ be "fixed". Unfortunately I'm not sure I'll be able
> to recall exactly what, but I thought I'd mention it as a word of
> caution, and in case it spurs anyone else's curiosity. Splitting any
> such PRs up by warning type would definitely be beneficial.
>
> On Fri, May 27, 2022 at 11:24 AM Eric Pugh
>  wrote:
> >
> > Also, I guess I need to be careful to run spotless after I make changes
> to the tests per package.
> >
> > On May 27, 2022, at 10:58 AM, Eric Pugh 
> wrote:
> >
> > Here is what I did the other night:
> >
> >
> https://github.com/apache/solr/compare/main...epugh:intellij_suggested_fixes
> >
> > I could just work on package by package, pushing them up, and if there
> is debate, I can just revert a commit on a package by package basis??
> >
> > Thoughts?
> >
> > Eric
> >
> >
> > On May 27, 2022, at 10:29 AM, Mike Drob  wrote:
> >
> > I would try to handle them in several small PRs either grouped by module
> or by warning type.
> >
> > On Fri, May 27, 2022 at 9:24 AM Eric Pugh <
> ep...@opensourceconnections.com> wrote:
> >>
> >> Hey all, was poking around at a unit test while watching TV and noticed
> lots of warnings from IntelliJ, little stuff like exceptions being thrown
> that don’t need to be thrown, unused variables, or typos.
> >>
> >> I was thinking about going through and fixing those, just to get the
> long list of problems down….  Is this best handled with a single PR with a
> JIRA issue?   Say a JIRA issue like “Clean up IntelliJ warnings for Test
> Code”?
> >>
> >> Eric
> >>
> >>
> >>
> >> ___
> >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467
> | http://www.opensourceconnections.com | My Free/Busy
> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> >> This e-mail and all contents, including attachments, is considered to
> be Company Confidential unless explicitly stated otherwise, regardless of
> whether attachments are marked as such.
> >>
> >
> > ___
> > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
> http://www.opensourceconnections.com | My Free/Busy
> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> > This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless of
> whether attachments are marked as such.
> >
> >
> > ___
> > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
> http://www.opensourceconnections.com | My Free/Busy
> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> > This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless of
> whether attachments are marked as such.
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>
>

-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Re: Cleaning up IntelliJ warnings in code base

[Michael Gibney]

I have a vague recollection of having seen intellij warnings that
really _shouldn't_ be "fixed". Unfortunately I'm not sure I'll be able
to recall exactly what, but I thought I'd mention it as a word of
caution, and in case it spurs anyone else's curiosity. Splitting any
such PRs up by warning type would definitely be beneficial.

On Fri, May 27, 2022 at 11:24 AM Eric Pugh
 wrote:
>
> Also, I guess I need to be careful to run spotless after I make changes to 
> the tests per package.
>
> On May 27, 2022, at 10:58 AM, Eric Pugh  
> wrote:
>
> Here is what I did the other night:
>
> https://github.com/apache/solr/compare/main...epugh:intellij_suggested_fixes
>
> I could just work on package by package, pushing them up, and if there is 
> debate, I can just revert a commit on a package by package basis??
>
> Thoughts?
>
> Eric
>
>
> On May 27, 2022, at 10:29 AM, Mike Drob  wrote:
>
> I would try to handle them in several small PRs either grouped by module or 
> by warning type.
>
> On Fri, May 27, 2022 at 9:24 AM Eric Pugh  
> wrote:
>>
>> Hey all, was poking around at a unit test while watching TV and noticed lots 
>> of warnings from IntelliJ, little stuff like exceptions being thrown that 
>> don’t need to be thrown, unused variables, or typos.
>>
>> I was thinking about going through and fixing those, just to get the long 
>> list of problems down….  Is this best handled with a single PR with a JIRA 
>> issue?   Say a JIRA issue like “Clean up IntelliJ warnings for Test Code”?
>>
>> Eric
>>
>>
>>
>> ___
>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
>> http://www.opensourceconnections.com | My Free/Busy
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> This e-mail and all contents, including attachments, is considered to be 
>> Company Confidential unless explicitly stated otherwise, regardless of 
>> whether attachments are marked as such.
>>
>
> ___
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
> http://www.opensourceconnections.com | My Free/Busy
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> This e-mail and all contents, including attachments, is considered to be 
> Company Confidential unless explicitly stated otherwise, regardless of 
> whether attachments are marked as such.
>
>
> ___
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
> http://www.opensourceconnections.com | My Free/Busy
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> This e-mail and all contents, including attachments, is considered to be 
> Company Confidential unless explicitly stated otherwise, regardless of 
> whether attachments are marked as such.
>

-
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

Re: Cleaning up IntelliJ warnings in code base

[Eric Pugh]

Also, I guess I need to be careful to run spotless after I make changes to the 
tests per package.

> On May 27, 2022, at 10:58 AM, Eric Pugh  
> wrote:
> 
> Here is what I did the other night:
> 
> https://github.com/apache/solr/compare/main...epugh:intellij_suggested_fixes 
> 
> 
> I could just work on package by package, pushing them up, and if there is 
> debate, I can just revert a commit on a package by package basis??
> 
> Thoughts?
> 
> Eric
> 
> 
>> On May 27, 2022, at 10:29 AM, Mike Drob > > wrote:
>> 
>> I would try to handle them in several small PRs either grouped by module or 
>> by warning type.
>> 
>> On Fri, May 27, 2022 at 9:24 AM Eric Pugh > > wrote:
>> Hey all, was poking around at a unit test while watching TV and noticed lots 
>> of warnings from IntelliJ, little stuff like exceptions being thrown that 
>> don’t need to be thrown, unused variables, or typos.
>> 
>> I was thinking about going through and fixing those, just to get the long 
>> list of problems down….  Is this best handled with a single PR with a JIRA 
>> issue?   Say a JIRA issue like “Clean up IntelliJ warnings for Test Code”?   
>> 
>> Eric
>> 
>> 
>> 
>> ___
>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
>> http://www.opensourceconnections.com  
>> | My Free/Busy   
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 
>> 
>>  
>> This e-mail and all contents, including attachments, is considered to be 
>> Company Confidential unless explicitly stated otherwise, regardless of 
>> whether attachments are marked as such.
>> 
> 
> ___
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
> http://www.opensourceconnections.com  
> | My Free/Busy   
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 
> 
>   
> This e-mail and all contents, including attachments, is considered to be 
> Company Confidential unless explicitly stated otherwise, regardless of 
> whether attachments are marked as such.
> 

___
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
http://www.opensourceconnections.com  | 
My Free/Busy   
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 


This e-mail and all contents, including attachments, is considered to be 
Company Confidential unless explicitly stated otherwise, regardless of whether 
attachments are marked as such.

Re: Cleaning up IntelliJ warnings in code base

[Eric Pugh]

Here is what I did the other night:

https://github.com/apache/solr/compare/main...epugh:intellij_suggested_fixes

I could just work on package by package, pushing them up, and if there is 
debate, I can just revert a commit on a package by package basis??

Thoughts?

Eric


> On May 27, 2022, at 10:29 AM, Mike Drob  wrote:
> 
> I would try to handle them in several small PRs either grouped by module or 
> by warning type.
> 
> On Fri, May 27, 2022 at 9:24 AM Eric Pugh  > wrote:
> Hey all, was poking around at a unit test while watching TV and noticed lots 
> of warnings from IntelliJ, little stuff like exceptions being thrown that 
> don’t need to be thrown, unused variables, or typos.
> 
> I was thinking about going through and fixing those, just to get the long 
> list of problems down….  Is this best handled with a single PR with a JIRA 
> issue?   Say a JIRA issue like “Clean up IntelliJ warnings for Test Code”?   
> 
> Eric
> 
> 
> 
> ___
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
> http://www.opensourceconnections.com  
> | My Free/Busy   
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 
> 
>   
> This e-mail and all contents, including attachments, is considered to be 
> Company Confidential unless explicitly stated otherwise, regardless of 
> whether attachments are marked as such.
> 

___
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
http://www.opensourceconnections.com  | 
My Free/Busy   
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 


This e-mail and all contents, including attachments, is considered to be 
Company Confidential unless explicitly stated otherwise, regardless of whether 
attachments are marked as such.

Re: Cleaning up IntelliJ warnings in code base

[Mike Drob]

I would try to handle them in several small PRs either grouped by module or
by warning type.

On Fri, May 27, 2022 at 9:24 AM Eric Pugh 
wrote:

> Hey all, was poking around at a unit test while watching TV and noticed
> lots of warnings from IntelliJ, little stuff like exceptions being thrown
> that don’t need to be thrown, unused variables, or typos.
>
> I was thinking about going through and fixing those, just to get the long
> list of problems down….  Is this best handled with a single PR with a JIRA
> issue?   Say a JIRA issue like “Clean up IntelliJ warnings for Test Code”?
>
>
> Eric
>
>
>
> ___
> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
> | http://www.opensourceconnections.com | My Free/Busy
> 
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> 
> This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless
> of whether attachments are marked as such.
>
>

Cleaning up IntelliJ warnings in code base

[Eric Pugh]

Hey all, was poking around at a unit test while watching TV and noticed lots of 
warnings from IntelliJ, little stuff like exceptions being thrown that don’t 
need to be thrown, unused variables, or typos.

I was thinking about going through and fixing those, just to get the long list 
of problems down….  Is this best handled with a single PR with a JIRA issue?   
Say a JIRA issue like “Clean up IntelliJ warnings for Test Code”?   

Eric



___
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
http://www.opensourceconnections.com  | 
My Free/Busy   
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 


This e-mail and all contents, including attachments, is considered to be 
Company Confidential unless explicitly stated otherwise, regardless of whether 
attachments are marked as such.