Re: 8.11.3 release

[Jan Høydahl]

Thanks Kevin, Ishan for doing the prep work here.

I re-enabled the jenkins job 
https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.11/ to get a 
feel for the current status. We also have a smokeTest job that should be 
enabled when release is approaching.

Jan

> 12. okt. 2023 kl. 19:38 skrev Kevin Risden :
> 
> I've pushed a few things to branch_8_11 recently
> *
> https://github.com/apache/lucene-solr/commit/e491400d961b771f146c6e12a7f8ed89eafe128f
> *
> https://github.com/apache/lucene-solr/commit/8e545e8f2154698e9bfeee92c40f8541fd7d0152
> *
> https://github.com/apache/lucene-solr/commit/e7560cd2ab024d4315933cd3965aab2961bba994
> 
> https://github.com/apache/lucene-solr/pull/2681 is in draft and updated a
> bunch of relatively low risk dependencies. There might be others we want to
> upgrade, but figured it was a decent start.
> 
> Kevin Risden
> 
> 
> On Thu, Oct 5, 2023 at 4:27 AM Pierre Salagnac 
> wrote:
> 
>> I just opened a pull request.
>> https://github.com/apache/lucene-solr/pull/2679
>> Details are in the PR.
>> 
>> Thanks !
>> 
>> Le lun. 2 oct. 2023 à 20:25, Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com>
>> a écrit :
>> 
>>> Thanks Pierre, I'll have it included in 8.11 once you are able to have a
>> PR
>>> for this. Thanks!
>>> 
>>> On Mon, 2 Oct 2023 at 22:22, Pierre Salagnac 
>>> wrote:
>>> 
 Hi Ishan,
 Sorry for the late chime in.
 
 Some time ago I filled a Jira for a Solr 8 specific bug:
 https://issues.apache.org/jira/browse/SOLR-16843
 
 At that time, I wasn't expecting more 8.x releases, so I did not open a
>>> PR
 for it.
 I can work on a fix if we have a few days more before the release. I
>>> think
 it is worth to have it in solr 8 (that's not a backport)
 
 Thanks
 
 
 Le ven. 29 sept. 2023 à 23:24, Ishan Chattopadhyaya <
 ichattopadhy...@gmail.com> a écrit :
 
> I'm going to track items from 9x releases in the following sheet.
> 
> 
 
>>> 
>> https://docs.google.com/spreadsheets/d/1FADkjDS0yfXpaUi3fbwsa7Izy5HOxE9AR_NKiss1sIo/edit#gid=0
> 
> Please let me know if there's any item there that you think would be
 useful
> to backport (if easy) to 8.11, and want me to take a look at
>>> backporting
> it.
> Regards,
> Ishan
> 
> On Tue, 19 Sept 2023 at 01:15, Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
> 
>> Just a reminder to backport any issues one sees fit for a 8.11.3
 release.
>> I'll try to get an RC out by the end of September, so still more
>>> than a
>> week away.
>> 
>> On Wed, 23 Aug 2023 at 17:09, Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>> 
>>> Hi Jan,
>>> Yes, still targeting September. But I will slip on my initial plan
>>> of
>>> doing it by first week of September. I'm foreseeing mid September
> timeframe.
>>> Thanks for checking in.
>>> Regards,
>>> Ishan
>>> 
>>> On Wed, 23 Aug, 2023, 5:05 pm Jan Høydahl, >> 
> wrote:
>>> 
 Hi,
 
 Following up on Ishan's proposed 8.11.3 release (
 https://lists.apache.org/thread/3xjtv1sxqx8f9nvhkc0cb90b2p76nfx2
>> )
 
 Does the Lucene project have any bugfix candidates for
>> backporting?
 
 Ishan, are you still targeting September?
 
 Jan
 
 
> 1. aug. 2023 kl. 14:57 skrev Ishan Chattopadhyaya <
 ichattopadhy...@gmail.com>:
> 
> Oh yes, good idea. Forgot about the split!
> 
> +Lucene Dev 
> 
> On Tue, 1 Aug, 2023, 6:17 pm Uwe Schindler, 
 wrote:
> 
>> Maybe ask on Lucene list, too, if there are some bug people
>> like
 to
 have
>> fixed in Lucene.
>> 
>> Uwe
>> 
>> Am 01.08.2023 um 11:10 schrieb Ishan Chattopadhyaya:
>>> Hi all,
>>> There have been lots of bug fixes that have gone into 9x that
> should
>>> benefit all 8x users as well.
>>> I thought of volunteering for such a 8.x release based on
>> this
 comment
>> [0].
>>> 
>>> Unless someone has any objections or concerns, can we
>>> tentatively
 plan
>> 1st
>>> September 2023 (1 month from now) as a tentative release for
> 8.11.3?
 I
>>> think we will get ample time to backport relevant fixes to 8x
>>> by
 then.
>>> 
>>> Best regards,
>>> Ishan
>>> 
>>> [0] -
>>> 
>> 
 
> 
 
>>> 
>> https://issues.apache.org/jira/browse/SOLR-16777?focusedCommentId=17742854&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17742854
>>> 
>> --
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de
>> eMail: u...@thetaphi.de
>

Re: 8.11.3 release

[Ishan Chattopadhyaya]

Thanks Jan. Some tests are failing; Noble and I are looking into them. If
all goes well, I'm planning to spin the RC1 by this weekend.

On Fri, 27 Oct, 2023, 2:45 pm Jan Høydahl,  wrote:

> Thanks Kevin, Ishan for doing the prep work here.
>
> I re-enabled the jenkins job
> https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.11/ to
> get a feel for the current status. We also have a smokeTest job that should
> be enabled when release is approaching.
>
> Jan
>
> > 12. okt. 2023 kl. 19:38 skrev Kevin Risden :
> >
> > I've pushed a few things to branch_8_11 recently
> > *
> >
> https://github.com/apache/lucene-solr/commit/e491400d961b771f146c6e12a7f8ed89eafe128f
> > *
> >
> https://github.com/apache/lucene-solr/commit/8e545e8f2154698e9bfeee92c40f8541fd7d0152
> > *
> >
> https://github.com/apache/lucene-solr/commit/e7560cd2ab024d4315933cd3965aab2961bba994
> >
> > https://github.com/apache/lucene-solr/pull/2681 is in draft and updated
> a
> > bunch of relatively low risk dependencies. There might be others we want
> to
> > upgrade, but figured it was a decent start.
> >
> > Kevin Risden
> >
> >
> > On Thu, Oct 5, 2023 at 4:27 AM Pierre Salagnac <
> pierre.salag...@gmail.com>
> > wrote:
> >
> >> I just opened a pull request.
> >> https://github.com/apache/lucene-solr/pull/2679
> >> Details are in the PR.
> >>
> >> Thanks !
> >>
> >> Le lun. 2 oct. 2023 à 20:25, Ishan Chattopadhyaya <
> >> ichattopadhy...@gmail.com>
> >> a écrit :
> >>
> >>> Thanks Pierre, I'll have it included in 8.11 once you are able to have
> a
> >> PR
> >>> for this. Thanks!
> >>>
> >>> On Mon, 2 Oct 2023 at 22:22, Pierre Salagnac <
> pierre.salag...@gmail.com>
> >>> wrote:
> >>>
>  Hi Ishan,
>  Sorry for the late chime in.
> 
>  Some time ago I filled a Jira for a Solr 8 specific bug:
>  https://issues.apache.org/jira/browse/SOLR-16843
> 
>  At that time, I wasn't expecting more 8.x releases, so I did not open
> a
> >>> PR
>  for it.
>  I can work on a fix if we have a few days more before the release. I
> >>> think
>  it is worth to have it in solr 8 (that's not a backport)
> 
>  Thanks
> 
> 
>  Le ven. 29 sept. 2023 à 23:24, Ishan Chattopadhyaya <
>  ichattopadhy...@gmail.com> a écrit :
> 
> > I'm going to track items from 9x releases in the following sheet.
> >
> >
> 
> >>>
> >>
> https://docs.google.com/spreadsheets/d/1FADkjDS0yfXpaUi3fbwsa7Izy5HOxE9AR_NKiss1sIo/edit#gid=0
> >
> > Please let me know if there's any item there that you think would be
>  useful
> > to backport (if easy) to 8.11, and want me to take a look at
> >>> backporting
> > it.
> > Regards,
> > Ishan
> >
> > On Tue, 19 Sept 2023 at 01:15, Ishan Chattopadhyaya <
> > ichattopadhy...@gmail.com> wrote:
> >
> >> Just a reminder to backport any issues one sees fit for a 8.11.3
>  release.
> >> I'll try to get an RC out by the end of September, so still more
> >>> than a
> >> week away.
> >>
> >> On Wed, 23 Aug 2023 at 17:09, Ishan Chattopadhyaya <
> >> ichattopadhy...@gmail.com> wrote:
> >>
> >>> Hi Jan,
> >>> Yes, still targeting September. But I will slip on my initial plan
> >>> of
> >>> doing it by first week of September. I'm foreseeing mid September
> > timeframe.
> >>> Thanks for checking in.
> >>> Regards,
> >>> Ishan
> >>>
> >>> On Wed, 23 Aug, 2023, 5:05 pm Jan Høydahl,  >>>
> > wrote:
> >>>
>  Hi,
> 
>  Following up on Ishan's proposed 8.11.3 release (
>  https://lists.apache.org/thread/3xjtv1sxqx8f9nvhkc0cb90b2p76nfx2
> >> )
> 
>  Does the Lucene project have any bugfix candidates for
> >> backporting?
> 
>  Ishan, are you still targeting September?
> 
>  Jan
> 
> 
> > 1. aug. 2023 kl. 14:57 skrev Ishan Chattopadhyaya <
>  ichattopadhy...@gmail.com>:
> >
> > Oh yes, good idea. Forgot about the split!
> >
> > +Lucene Dev 
> >
> > On Tue, 1 Aug, 2023, 6:17 pm Uwe Schindler, 
>  wrote:
> >
> >> Maybe ask on Lucene list, too, if there are some bug people
> >> like
>  to
>  have
> >> fixed in Lucene.
> >>
> >> Uwe
> >>
> >> Am 01.08.2023 um 11:10 schrieb Ishan Chattopadhyaya:
> >>> Hi all,
> >>> There have been lots of bug fixes that have gone into 9x that
> > should
> >>> benefit all 8x users as well.
> >>> I thought of volunteering for such a 8.x release based on
> >> this
>  comment
> >> [0].
> >>>
> >>> Unless someone has any objections or concerns, can we
> >>> tentatively
>  plan
> >> 1st
> >>> September 2023 (1 month from now) as a tentative release for
> > 8.11.3?
>  I
> >>> think we will get ample time to ba

Re: How about using JDK 21 in the official docker image?

[Houston Putman]

Those images are available now.

https://hub.docker.com/r/apache/solr-nightly/tags?page=1&name=java21

Also I setup the Jenkins jobs to only push the tags if the docker tests
pass, so we at least have that guarantee!

Hopefully we can get a good amount of testing with these and upgrade when
java 21 is a little bit older.

- Houston

On Thu, Oct 26, 2023 at 2:50 PM Houston Putman  wrote:

> I've changed the nightly docker jobs to also create "-java21" images for
> main, branch_9x and branch_9_4, so we can start testing this out before
> making it official.
>
> The new images should become available in the next 24 hours.
>
> e.g. apache/solr-nightly:9.4.1-SNAPSHOT-java21
>
> - Houston
>
> On Thu, Oct 26, 2023 at 12:19 PM Houston Putman 
> wrote:
>
>> We could also use Java 21 for the 9x and main nightly images! Easy to
>> change it in the Jenkins jobs
>>
>> - Houston
>>
>> On Wed, Oct 25, 2023 at 6:22 PM Jan Høydahl 
>> wrote:
>>
>>> I agree on being conservative here. But if it turns out to work well, we
>>> could consider publishing an additional solr:9.4.0-jre21 tag. That way
>>> early adopters have a choice. If I remember correctly, Java 21 has some
>>> improvements that can benefit some vector workloads or something, so I see
>>> a benefit in getting it out there. We could alternatively opt to push
>>> temporary images like this to our own apache/solr docker namespace for
>>> folks to try out.
>>>
>>> Jan
>>>
>>> > 24. okt. 2023 kl. 18:17 skrev Shawn Heisey >> >:
>>> >
>>> > On 10/18/2023 10:11 AM, Tomasz Elendt wrote:
>>> >> I noticed that JDK 21 LTS was released some time ago. Is there any
>>> reason why official docker images still use JDK 17?
>>> >> I'm asking because I know there are some preview JDK features that
>>> Lucene utilizes and Solr enables them when it detects a newer version (e.g.
>>> SOLR-16500).
>>> >> Does it make sense to switch now that there is a new LTS version?
>>> >
>>> > I have no desire to stand in the way of progress, but Java 21 has only
>>> been out for a month.  I don't think it's a good idea to rely on a new
>>> major version of *anything* that soon after its release.  Test with it, but
>>> don't switch to it.
>>> >
>>> > I do not think we should be planning on such a major upgrade to the
>>> docker image until Java 21 has been out for a while.  I was going to
>>> upgrade my Solr server to Java 21 to try it out since it's not a mission
>>> critical install, but Ubuntu doesn't yet have OpenJDK packages for it. The
>>> eclipse-temurin:21-jre-jammy docker image was pushed 11 days ago.
>>> >
>>> > My thought on it is to wait until at least the release of Java 22,
>>> which will happen six months after Java 21 was released.
>>> >
>>> > Thanks,
>>> > Shawn
>>> >
>>> > -
>>> > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>>> > For additional commands, e-mail: dev-h...@solr.apache.org
>>> >
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>>> For additional commands, e-mail: dev-h...@solr.apache.org
>>>
>>>

Re: Jenkins Build Errors

[Houston Putman]

After fixing the docker tests, I believe all of the other Solr-Check and
Solr-Smoketest errors, that were the result of running Solr processes, have
gone away.
The MTLs issue still exists, and there are other issues with the
smoketest but at least there is progress.

We should definitely move the docker tests to use BATS so that we can have
better control over test cleanup. But that's not going to be a very easy
migration.

- Houston

On Thu, Oct 26, 2023 at 1:00 PM Houston Putman  wrote:

> Ok, I think I fixed the docker tests. The other issues all still apply
> though.
>
> - Houston
>
> On Thu, Oct 26, 2023 at 12:16 PM Houston Putman 
> wrote:
>
>> The Jenkins builds aren't in a great state right now.
>>
>> Currently the Solr-Check-main
>>  build is
>> failing consistently because of random Solr processes being found on the
>> box (when the integration tests expect nothing else to be running). Now
>> that we have port randomization for the integration tests, its a very good
>> sign that the found Solr processes all use port 8983, meaning that we
>> aren't leaking Solrs in the integration tests.
>>
>> Because of this, the culprit seems to be that the smoke tests (which
>> still start a Solr on port 8983) are leaking processes, and looking at the
>> logs, that seems to be the case (Solr-Smoketest-9.4
>> ,
>> Solr-Smoketest-9.x
>> ). So
>> fixing the Smoketests leaking Solr processes will in turn fix both the
>> smoke test builds and the main check.
>>
>> As for the Solr-Check-9.x
>>  build, it is
>> running on Crave, so it doesn't have the same issue with leaked Solr
>> processes. However on crave, there seems to be an issue with the mTLS
>> tests. (Solr-Check-main also has this issue, but only on the lucene-solr-1
>> machine, not lucene-solr-2 strangely). We need to investigate why the TLS
>> tests pass locally for everyone (and on 1/2 of the Jenkins boxes), but not
>> on crave.
>>
>> Lastly, the Docker tests are broken in a very strange way. A while ago, I
>> added tests to make sure that the prometheus exporter can communicate
>> correctly in docker. This test seems to fail on both
>> Solr-Docker-Nightly-main
>>  and
>> Solr-Docker-Nightly-9.x
>> . At
>> first I thought the issue was that the Jenkins servers had different Docker
>> networking that didn't support these tests, and I let it be for a bit. Now
>> we are running Solr-Docker-Nightly-9.4
>> ,
>> which has the same tests included and it passes. So it does seem like the
>> Jenkins servers allow us to use Docker networking in the ways we want, but
>> for some reason 9.x and 9.4 (which should be relatively identical) don't
>> behave the same way. Looking at the err logs, the problem is
>>
>>> /opt/solr/docker/scripts/docker-entrypoint.sh: line 48: exec:
>>> solr-exporter: not found
>>>
>> On the top of my head I think this might be using the slim docker image?
>> Because otherwise there's no reason why the solr exporter wouldn't be
>> there... (Also no idea why it wouldn't work the same on the 9.4 build...)
>>
>> Anyways, this is just a list of what's going on. I'll try to fix the
>> docker stuff, but would love help with the other builds!
>>
>> - Houston
>>
>

Re: Jenkins Build Errors

[David Smiley]

Thanks Houston!
~ David


On Fri, Oct 27, 2023 at 2:03 PM Houston Putman  wrote:

> After fixing the docker tests, I believe all of the other Solr-Check and
> Solr-Smoketest errors, that were the result of running Solr processes, have
> gone away.
> The MTLs issue still exists, and there are other issues with the
> smoketest but at least there is progress.
>
> We should definitely move the docker tests to use BATS so that we can have
> better control over test cleanup. But that's not going to be a very easy
> migration.
>
> - Houston
>
> On Thu, Oct 26, 2023 at 1:00 PM Houston Putman  wrote:
>
> > Ok, I think I fixed the docker tests. The other issues all still apply
> > though.
> >
> > - Houston
> >
> > On Thu, Oct 26, 2023 at 12:16 PM Houston Putman 
> > wrote:
> >
> >> The Jenkins builds aren't in a great state right now.
> >>
> >> Currently the Solr-Check-main
> >>  build is
> >> failing consistently because of random Solr processes being found on the
> >> box (when the integration tests expect nothing else to be running). Now
> >> that we have port randomization for the integration tests, its a very
> good
> >> sign that the found Solr processes all use port 8983, meaning that we
> >> aren't leaking Solrs in the integration tests.
> >>
> >> Because of this, the culprit seems to be that the smoke tests (which
> >> still start a Solr on port 8983) are leaking processes, and looking at
> the
> >> logs, that seems to be the case (Solr-Smoketest-9.4
> >> ,
> >> Solr-Smoketest-9.x
> >> ). So
> >> fixing the Smoketests leaking Solr processes will in turn fix both the
> >> smoke test builds and the main check.
> >>
> >> As for the Solr-Check-9.x
> >>  build, it is
> >> running on Crave, so it doesn't have the same issue with leaked Solr
> >> processes. However on crave, there seems to be an issue with the mTLS
> >> tests. (Solr-Check-main also has this issue, but only on the
> lucene-solr-1
> >> machine, not lucene-solr-2 strangely). We need to investigate why the
> TLS
> >> tests pass locally for everyone (and on 1/2 of the Jenkins boxes), but
> not
> >> on crave.
> >>
> >> Lastly, the Docker tests are broken in a very strange way. A while ago,
> I
> >> added tests to make sure that the prometheus exporter can communicate
> >> correctly in docker. This test seems to fail on both
> >> Solr-Docker-Nightly-main
> >> 
> and
> >> Solr-Docker-Nightly-9.x
> >> . At
> >> first I thought the issue was that the Jenkins servers had different
> Docker
> >> networking that didn't support these tests, and I let it be for a bit.
> Now
> >> we are running Solr-Docker-Nightly-9.4
> >> ,
> >> which has the same tests included and it passes. So it does seem like
> the
> >> Jenkins servers allow us to use Docker networking in the ways we want,
> but
> >> for some reason 9.x and 9.4 (which should be relatively identical) don't
> >> behave the same way. Looking at the err logs, the problem is
> >>
> >>> /opt/solr/docker/scripts/docker-entrypoint.sh: line 48: exec:
> >>> solr-exporter: not found
> >>>
> >> On the top of my head I think this might be using the slim docker image?
> >> Because otherwise there's no reason why the solr exporter wouldn't be
> >> there... (Also no idea why it wouldn't work the same on the 9.4
> build...)
> >>
> >> Anyways, this is just a list of what's going on. I'll try to fix the
> >> docker stuff, but would love help with the other builds!
> >>
> >> - Houston
> >>
> >
>

Re: forbidden-apis + assertThat = insanity

[David Smiley]

This would be cleared up if we change LuceneTestCase?
~ David


On Wed, Oct 25, 2023 at 4:26 PM Chris Hostetter 
wrote:

>
> Begin Rant...
>
> $ tail -6 ./gradle/validation/forbidden-apis/junit.junit.all.txt
> junit.framework.TestCase @ All classes should derive from LuceneTestCase
> junit.framework.Assert @ Use org.junit.Assert
> junit.framework.** @ Use org.junit
> org.junit.Assert#assertThat(**) @ Use
> org.hamcrest.MatcherAssert.assertThat()
> org.junit.matchers.JUnitMatchers @ Use org.hamcrest.CoreMatchers
> org.junit.rules.ExpectedException @ Use Assert.assertThrows
>
> So all test classes should:
>   - derive from LuceneTestCase (agreed)
>   - use org.junit.Assert instead of junit.framework.Assert (fair enough)
>   - use MatcherAssert.assertThat() instead of Assert.assertThat() ...
>
> ...ok, i guess?  ... except that LuceneTestCase extends Assert, giving us
> Assert.assertThat() for free.  Kind of anoying to have to go out of our
> way to import another class to do the same thing.
>
> But also ... you can't just use...
>
>   import static org.hamcrest.MatcherAssert.assertThat;
>
> ...because (assuming you're following best practices) you're already
> inheriting from LuceneTestCase, so that static import is going to be
> unused since it conflicts with the inherited 'assertThat' -- or at least
> that's what ecjLintTest tells you ... i'm not 100% certain it's correct,
> but either way you can't use it because it will fails the build.
>
> So your only recourse is to use...
>
>   import org.hamcrest.MatcherAssert;
>
> ...and now instead of lots of nice short 'assertThat(...)' method calls
> you have to use the twice as long 'MatcherAssert.assertThat', which is
> probably going to make spotless decide your assertions needs to span at
> least one extra line (assuming you are using descriptive variable names)
>
> All because we don't want want devs to use a (deprecated) method
> that's indirectly inherited from an ancestor of a baseclass we tell them
> to use.
>
> Which begs the questions:
>
> - What is so terrible about the impl of Assert.assertThat?
> - What evil does it contain that makes it completely unssuitable for use?
>
> Let's go find out what exactly we are asking forbidden-apis to
> shield us from...
>
>
> https://github.com/junit-team/junit4/blob/r4.13.2/src/main/java/org/junit/Assert.java#L962
>
>  public static  void assertThat(String reason, T actual,
>  Matcher matcher) {
>  MatcherAssert.assertThat(reason, actual, matcher);
>  }
>
> ...oh dear lord ... what sweet horror is this??!?!?!!?
>
> Thank heavens we were wise enough to protect ourselves from this
> unspeakably dangerous code!
>
>
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>
>

Re: 8.11.3 release

[Jan Høydahl]

I also enabled the smoketest job, and it passes: 
https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-SmokeRelease-8.11/lastSuccessfulBuild/
 !

The Lucene-Solr-Tests-8.11 has failed a few times, but on different tests, so 
things are looking good.

Jan

> 27. okt. 2023 kl. 13:55 skrev Ishan Chattopadhyaya 
> :
> 
> Thanks Jan. Some tests are failing; Noble and I are looking into them. If
> all goes well, I'm planning to spin the RC1 by this weekend.
> 
> On Fri, 27 Oct, 2023, 2:45 pm Jan Høydahl,  wrote:
> 
>> Thanks Kevin, Ishan for doing the prep work here.
>> 
>> I re-enabled the jenkins job
>> https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.11/ to
>> get a feel for the current status. We also have a smokeTest job that should
>> be enabled when release is approaching.
>> 
>> Jan
>> 
>>> 12. okt. 2023 kl. 19:38 skrev Kevin Risden :
>>> 
>>> I've pushed a few things to branch_8_11 recently
>>> *
>>> 
>> https://github.com/apache/lucene-solr/commit/e491400d961b771f146c6e12a7f8ed89eafe128f
>>> *
>>> 
>> https://github.com/apache/lucene-solr/commit/8e545e8f2154698e9bfeee92c40f8541fd7d0152
>>> *
>>> 
>> https://github.com/apache/lucene-solr/commit/e7560cd2ab024d4315933cd3965aab2961bba994
>>> 
>>> https://github.com/apache/lucene-solr/pull/2681 is in draft and updated
>> a
>>> bunch of relatively low risk dependencies. There might be others we want
>> to
>>> upgrade, but figured it was a decent start.
>>> 
>>> Kevin Risden
>>> 
>>> 
>>> On Thu, Oct 5, 2023 at 4:27 AM Pierre Salagnac <
>> pierre.salag...@gmail.com>
>>> wrote:
>>> 
 I just opened a pull request.
 https://github.com/apache/lucene-solr/pull/2679
 Details are in the PR.
 
 Thanks !
 
 Le lun. 2 oct. 2023 à 20:25, Ishan Chattopadhyaya <
 ichattopadhy...@gmail.com>
 a écrit :
 
> Thanks Pierre, I'll have it included in 8.11 once you are able to have
>> a
 PR
> for this. Thanks!
> 
> On Mon, 2 Oct 2023 at 22:22, Pierre Salagnac <
>> pierre.salag...@gmail.com>
> wrote:
> 
>> Hi Ishan,
>> Sorry for the late chime in.
>> 
>> Some time ago I filled a Jira for a Solr 8 specific bug:
>> https://issues.apache.org/jira/browse/SOLR-16843
>> 
>> At that time, I wasn't expecting more 8.x releases, so I did not open
>> a
> PR
>> for it.
>> I can work on a fix if we have a few days more before the release. I
> think
>> it is worth to have it in solr 8 (that's not a backport)
>> 
>> Thanks
>> 
>> 
>> Le ven. 29 sept. 2023 à 23:24, Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> a écrit :
>> 
>>> I'm going to track items from 9x releases in the following sheet.
>>> 
>>> 
>> 
> 
 
>> https://docs.google.com/spreadsheets/d/1FADkjDS0yfXpaUi3fbwsa7Izy5HOxE9AR_NKiss1sIo/edit#gid=0
>>> 
>>> Please let me know if there's any item there that you think would be
>> useful
>>> to backport (if easy) to 8.11, and want me to take a look at
> backporting
>>> it.
>>> Regards,
>>> Ishan
>>> 
>>> On Tue, 19 Sept 2023 at 01:15, Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>> 
 Just a reminder to backport any issues one sees fit for a 8.11.3
>> release.
 I'll try to get an RC out by the end of September, so still more
> than a
 week away.
 
 On Wed, 23 Aug 2023 at 17:09, Ishan Chattopadhyaya <
 ichattopadhy...@gmail.com> wrote:
 
> Hi Jan,
> Yes, still targeting September. But I will slip on my initial plan
> of
> doing it by first week of September. I'm foreseeing mid September
>>> timeframe.
> Thanks for checking in.
> Regards,
> Ishan
> 
> On Wed, 23 Aug, 2023, 5:05 pm Jan Høydahl,  
>>> wrote:
> 
>> Hi,
>> 
>> Following up on Ishan's proposed 8.11.3 release (
>> https://lists.apache.org/thread/3xjtv1sxqx8f9nvhkc0cb90b2p76nfx2
 )
>> 
>> Does the Lucene project have any bugfix candidates for
 backporting?
>> 
>> Ishan, are you still targeting September?
>> 
>> Jan
>> 
>> 
>>> 1. aug. 2023 kl. 14:57 skrev Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com>:
>>> 
>>> Oh yes, good idea. Forgot about the split!
>>> 
>>> +Lucene Dev 
>>> 
>>> On Tue, 1 Aug, 2023, 6:17 pm Uwe Schindler, 
>> wrote:
>>> 
 Maybe ask on Lucene list, too, if there are some bug people
 like
>> to
>> have
 fixed in Lucene.
 
 Uwe
 
 Am 01.08.2023 um 11:10 schrieb Ishan Chattopadhyaya:
> Hi all,
> There have been lots of bug fixes that have gone into 9x that
>>> should
> benefit all 8x users as well.
>>>

Re: forbidden-apis + assertThat = insanity

[Chris Hostetter]

: I agree that having to write "MatcherAssert.assertThat" each time is
: tedious and makes my code ugly. So finally I try to avoid this nice
: construction. Not satisfying.

This right there is the "twist" of the knife in my heart.  

The 2 lines of code below are both very similar in terms of ease of 
writing/reading, but the one that produces a message that might actually 
be helpful in the event that it fails is the one we actively make harder 
for devs to write...

   assertTrue( obj instanceof Foo );

   assertThat( obj, instanceOf(Foo.class) );

...guess which one is in our code base 14 times, and which one is in our 
code base 700+ times?


: > Basically it removes a ton of deprecated usages. If/when we upgrade Junit
: > we should hopefully have much less to do.

It seems disingenuous for us, as a project, to say "We care so much about 
avoiding deprecated methods we're going to make it harder for contributers 
to write good unit tests" when at the sametime we actively prevent the 
compiler from printing warnings about deprecations...

$ grep deprecation gradle/java/javac.gradle
"-Xlint:-deprecation",

...but let's go with it, and assume forbidden-api is just a stop gap 
measure until we eventually manage to eliminate all deprecated code usage 
from the code base...

: > It came in as part of
: > https://github.com/apache/solr/pull/947#issuecomment-1279651282
: >
: > I linked to one of the comments there since this was discussed on the PR.

I'm going to highlight the 2 key sentence in this comment...

>> So we can't override assertThat in SolrTestCase since its 
>> static and comes from Assert which is what LuceneTestCase 
>> derives from. ForbiddenApis correctly complains that we 
>> can't just override the static method and instead knows 
>> that Assert#assertThat is still being called.

Unless I'm missing something major...

  1. The first sentence is true, but inaccurate.  
  2. The second sentence is false, but accurate.  :)

1) java does not allow overloading -- in the strict polymorphic sense -- 
of static methods, but that is completley irelevant to us.  What matters 
is that java *does* allow static method "hiding" -- (re)defining a static 
method using the same signature as a static method provided by your based 
class, ensuring that other code in your class (or subclasses) that attempt 
to invoke that method signature will get your version of it. (unless the 
use the fully qualified name of your parent class) ... 
https://docs.oracle.com/javase/tutorial/java/IandI/override.html

2) AFAICT Forbidden APIs *incorrectly* complains that you are calling a 
forbidden method if you "hide" a forbidden static method by defining a new 
impl of that method signature in your code -- even though the new impl is 
what actaully gets called... 
https://github.com/policeman-tools/forbidden-apis/issues/237

...so if/when forbidden-apis #237 can be resolved, we can have the best of 
both worlds.


-Hoss
http://www.lucidworks.com/

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