How to run Lucene 9 tests in eclipse?
Hi All, How can we run Lucene9 tests via eclipse? I am able to run all the tests through the command line but not with eclipse. Please advise!
Re: Simplify the release artifacts
Well there's definitely a good reason to stop publishing convenience binaries: they aren't required. Lucene is a library. I think it makes sense to publish convenience binaries for the luke App, that's it. Otherwise, we should publish just source code, that's all that is required. Library users want to use build systems like gradle and maven, so we should put the classfiles there too. But there's zero requirement to make zips and tgzs of .class files and 3rd party libs up on the website. zero. and if no one is using them, we should stop doing it. Instead i'd rather focus on testing of what counts (e.g. do those jar files going to maven have included javadocs so it works well in the IDE?). These aspects are more important for a library. On Mon, Oct 11, 2021 at 8:21 PM Jan Høydahl wrote: > > +1 to all suggestions. > > ASF has a release policy > (https://www.apache.org/legal/release-policy.html#release-distribution) and > artifacts must be uploaded to the mirrors. > There is also a release distribution policy > (https://infra.apache.org/release-distribution.html#download-links) that says > >"The website documentation for any Apache product must provide public > download links where interested parties may obtain current official source > releases and accompanying cryptographic files." > > So I see no reason to stop publishing binary convenience releases in the > apache mirrors, although few will use that channel. > > Jan > > 12. okt. 2021 kl. 01:55 skrev Tomoko Uchida : > > For what it's worth, I did a little survey on how other > library/sdk/framework projects distribute their artifacts other than > Maven repositories. > > - Log4j distributes tgz and zip artifacts via the "Download" page. > https://logging.apache.org/log4j/2.x/download.html > > - JavaFX distributes only zip artifacts via the "Download" page > https://gluonhq.com/products/javafx/ > > - Jersey has a "Download" page but it is actually a facade to Maven Central. > https://eclipse-ee4j.github.io/jersey/download.html > > - JUnit5 has no "download" page > https://junit.org/junit5/ > > - Spring has no "download" page (as far as I know) > https://spring.io/projects/spring-framework > > - Jackson has no "download" page (github repo also serves as their > documentation). > https://github.com/FasterXML/jackson-core > > They are only small examples, but it seems to me that recent or > recently renewed projects would tend to have no explicit "download" > page at all. (?) > I'm not sure there are any ASF rules or policies about that. > > Tomoko > > 2021年10月11日(月) 21:59 Robert Muir : > > > +1 overall, comments inline. > > On Mon, Oct 11, 2021 at 7:48 AM Dawid Weiss wrote: > > > Hi. > > These are the thoughts that occurred to me while rewriting the > packaging in the build system. I think they're worth the discussion > because they could limit the size of the published artifacts as well > as their perceptive quality. > > 1. Who is going to use the lib/*.jar files we distribute in binary > releases? I don't think they are useful for anything. The dependency > information for modules is stored in maven POMs (and can be easily > written to text files, if it's really something people are dying to > preserve). > > > +1 > > > I don't think redistributing those JARs makes any sense other than to > make Luke work... What I would suggest is to remove third-party JARs > entirely from the binary distribution and have a separate binary > artifact with a fully functional top-level Luke application. > Alternatively, move those third-party JARs to the top-level > /thirdparty folder and Luke can access them from there. > > > +1, I think there is already an issue open to give luke its own > "release artifact" > > > 2. Some of the *.txt files both at the top-level and inside subfolders > contain obsolete information. We should at least re-read these. My > personal opinion is that some of the README.txt files inside modules > have little practical use - their content should go inside the javadoc > (package level, perhaps) and this should be the only source of > documentation. > > > +1, either nuke it, or fold it into javadoc, or at the very least > rename to README.md > > > 3. I would remove the "zip" binary distribution. I'm on Windows myself > so tgz is a tad more difficult to work with but Lucene is a library. > If somebody downloads a binary distribution they should know how to > unpack a tgz file (cygwin, total commander, whatever else). > > > +1 > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > - To unsubscribe, e-mail:
Re: Simplify the release artifacts
+1 to all suggestions. ASF has a release policy (https://www.apache.org/legal/release-policy.html#release-distribution) and artifacts must be uploaded to the mirrors. There is also a release distribution policy (https://infra.apache.org/release-distribution.html#download-links) that says "The website documentation for any Apache product must provide public download links where interested parties may obtain current official source releases and accompanying cryptographic files." So I see no reason to stop publishing binary convenience releases in the apache mirrors, although few will use that channel. Jan > 12. okt. 2021 kl. 01:55 skrev Tomoko Uchida : > > For what it's worth, I did a little survey on how other > library/sdk/framework projects distribute their artifacts other than > Maven repositories. > > - Log4j distributes tgz and zip artifacts via the "Download" page. > https://logging.apache.org/log4j/2.x/download.html > > - JavaFX distributes only zip artifacts via the "Download" page > https://gluonhq.com/products/javafx/ > > - Jersey has a "Download" page but it is actually a facade to Maven Central. > https://eclipse-ee4j.github.io/jersey/download.html > > - JUnit5 has no "download" page > https://junit.org/junit5/ > > - Spring has no "download" page (as far as I know) > https://spring.io/projects/spring-framework > > - Jackson has no "download" page (github repo also serves as their > documentation). > https://github.com/FasterXML/jackson-core > > They are only small examples, but it seems to me that recent or > recently renewed projects would tend to have no explicit "download" > page at all. (?) > I'm not sure there are any ASF rules or policies about that. > > Tomoko > > 2021年10月11日(月) 21:59 Robert Muir : >> >> +1 overall, comments inline. >> >> On Mon, Oct 11, 2021 at 7:48 AM Dawid Weiss wrote: >>> >>> Hi. >>> >>> These are the thoughts that occurred to me while rewriting the >>> packaging in the build system. I think they're worth the discussion >>> because they could limit the size of the published artifacts as well >>> as their perceptive quality. >>> >>> 1. Who is going to use the lib/*.jar files we distribute in binary >>> releases? I don't think they are useful for anything. The dependency >>> information for modules is stored in maven POMs (and can be easily >>> written to text files, if it's really something people are dying to >>> preserve). >> >> +1 >> >>> >>> I don't think redistributing those JARs makes any sense other than to >>> make Luke work... What I would suggest is to remove third-party JARs >>> entirely from the binary distribution and have a separate binary >>> artifact with a fully functional top-level Luke application. >>> Alternatively, move those third-party JARs to the top-level >>> /thirdparty folder and Luke can access them from there. >> >> +1, I think there is already an issue open to give luke its own >> "release artifact" >> >>> >>> 2. Some of the *.txt files both at the top-level and inside subfolders >>> contain obsolete information. We should at least re-read these. My >>> personal opinion is that some of the README.txt files inside modules >>> have little practical use - their content should go inside the javadoc >>> (package level, perhaps) and this should be the only source of >>> documentation. >> >> +1, either nuke it, or fold it into javadoc, or at the very least >> rename to README.md >> >>> >>> 3. I would remove the "zip" binary distribution. I'm on Windows myself >>> so tgz is a tad more difficult to work with but Lucene is a library. >>> If somebody downloads a binary distribution they should know how to >>> unpack a tgz file (cygwin, total commander, whatever else). >> >> +1 >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org >
Re: Simplify the release artifacts
For what it's worth, I did a little survey on how other library/sdk/framework projects distribute their artifacts other than Maven repositories. - Log4j distributes tgz and zip artifacts via the "Download" page. https://logging.apache.org/log4j/2.x/download.html - JavaFX distributes only zip artifacts via the "Download" page https://gluonhq.com/products/javafx/ - Jersey has a "Download" page but it is actually a facade to Maven Central. https://eclipse-ee4j.github.io/jersey/download.html - JUnit5 has no "download" page https://junit.org/junit5/ - Spring has no "download" page (as far as I know) https://spring.io/projects/spring-framework - Jackson has no "download" page (github repo also serves as their documentation). https://github.com/FasterXML/jackson-core They are only small examples, but it seems to me that recent or recently renewed projects would tend to have no explicit "download" page at all. (?) I'm not sure there are any ASF rules or policies about that. Tomoko 2021年10月11日(月) 21:59 Robert Muir : > > +1 overall, comments inline. > > On Mon, Oct 11, 2021 at 7:48 AM Dawid Weiss wrote: > > > > Hi. > > > > These are the thoughts that occurred to me while rewriting the > > packaging in the build system. I think they're worth the discussion > > because they could limit the size of the published artifacts as well > > as their perceptive quality. > > > > 1. Who is going to use the lib/*.jar files we distribute in binary > > releases? I don't think they are useful for anything. The dependency > > information for modules is stored in maven POMs (and can be easily > > written to text files, if it's really something people are dying to > > preserve). > > +1 > > > > > I don't think redistributing those JARs makes any sense other than to > > make Luke work... What I would suggest is to remove third-party JARs > > entirely from the binary distribution and have a separate binary > > artifact with a fully functional top-level Luke application. > > Alternatively, move those third-party JARs to the top-level > > /thirdparty folder and Luke can access them from there. > > +1, I think there is already an issue open to give luke its own > "release artifact" > > > > > 2. Some of the *.txt files both at the top-level and inside subfolders > > contain obsolete information. We should at least re-read these. My > > personal opinion is that some of the README.txt files inside modules > > have little practical use - their content should go inside the javadoc > > (package level, perhaps) and this should be the only source of > > documentation. > > +1, either nuke it, or fold it into javadoc, or at the very least > rename to README.md > > > > > 3. I would remove the "zip" binary distribution. I'm on Windows myself > > so tgz is a tad more difficult to work with but Lucene is a library. > > If somebody downloads a binary distribution they should know how to > > unpack a tgz file (cygwin, total commander, whatever else). > > +1 > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Bugfix release Lucene/Solr 8.10.1
Hi Mike, thank you for letting me know about it. I haven't started to build a RC yet, so your commit is fine, your change will be included in 8.10.1. On Mon, Oct 11, 2021 at 7:33 PM Mike Drob wrote: > Hi Mayya, I just committed SOLR-15269 to the release branch, a very minor > dependency update. My apologies for not coming and checking in the thread > first. Please let me know if this is ok, I can revert if you need me to. > Thanks for handling the release! > > On Sun, Oct 10, 2021 at 9:04 PM Mayya Sharipova > wrote: > >> Thank you for the suggestion, Jan, I will follow it. >> >> On Sun, Oct 10, 2021 at 5:27 PM Jan Høydahl >> wrote: >> >>> Remember that the releaseWizard on 8x repo is not prepared with correct >>> commands to update the 'main' repos properly. So each time it asks you to >>> do stuff on 'master'/unstable branch you must instead manually adapt andd >>> perform those steps on the new apache/lucene and apache/solr repos. >>> >>> Jan >>> >>> 10. okt. 2021 kl. 13:45 skrev Mayya Sharipova : >>> >>> Hi Houston, >>> Thank you for bringing this to my attention, I've corrected the 8.10.1 >>> changelog for all the branches. >>> >>> Thanks a lot. >>> >>> On Fri, Oct 8, 2021 at 11:44 PM Houston Putman >>> wrote: >>> Hey Mayya, I think there are some issues with the lucene changelog entries in 8.10.1 across various branches (branch_8_10, branch_8x, and main). I don't see LUCENE-10119, and LUCENE-10126 is marked as an 8.11.0 entry in at least branch_8x. - Houston On Thu, Oct 7, 2021 at 9:32 PM Mayya Sharipova < mayya.sharip...@elastic.co.invalid> wrote: > Hello everyone, > > I am now preparing for a bugfix release from branch branch_8_10 > > Please observe the normal rules for committing to this branch: > > * Before committing to the branch, reply to this thread and argue > why the fix needs backporting and how long it will take. > * All issues accepted for backporting should be marked with 8.10.1 > in JIRA, and issues that should delay the release must be marked as > Blocker > * All patches that are intended for the branch should first be > committed > to the unstable branch, merged into the stable branch, and then into > the current release branch. > * Only Jira issues with Fix version 8.10.1 and priority "Blocker" will > delay > a release candidate build. > > - > Currently we have the following committed for 8.10.1 > LUCENE-10119: Do not set single sort with search after > LUCENE-10126: Fix competitive iterator wrongly skip docs > SOLR-15572: Fix a test failure caused by simplistic line parsing. > SOLR-15665: Move polling logic under main > > - > We have the following bug fixes already resolved in 8.11. > Does anyone from the list below want to backport their fixes for > 8.10.1 release as well? Please let me know by Monday > > * LUCENE-10110: MultiCollector now handles single leaf collector that > wants to skip low-scoring hits but the combined score mode doesn't allow > it. (Jim Ferenczi) > * LUCENE-10111: Missing calculating the bytes used of DocsWithFieldSet > in NormValuesWriter. (Lu Xugang) > * LUCENE-10116: Missing calculating the bytes used of > DocsWithFieldSetand currentValues in SortedSetDocValuesWriter. (Lu Xugang) > * LUCENE-10070 Skip deleted docs when accumulating facet counts for > all docs. (Ankur Goel, Greg Miller) > * LUCENE-10134: ConcurrentSortedSetDocValuesFacetCounts shouldn't > share liveDocs Bits across threads. (Ankur Goel) > * SOLR-15626: Config-read permission does not allow access to > /solr/admin/configs?action=LIST (Jon Senchyna) > > > Thanks. > > > >>>
Re: Bugfix release Lucene/Solr 8.10.1
Hi Mayya, I just committed SOLR-15269 to the release branch, a very minor dependency update. My apologies for not coming and checking in the thread first. Please let me know if this is ok, I can revert if you need me to. Thanks for handling the release! On Sun, Oct 10, 2021 at 9:04 PM Mayya Sharipova wrote: > Thank you for the suggestion, Jan, I will follow it. > > On Sun, Oct 10, 2021 at 5:27 PM Jan Høydahl wrote: > >> Remember that the releaseWizard on 8x repo is not prepared with correct >> commands to update the 'main' repos properly. So each time it asks you to >> do stuff on 'master'/unstable branch you must instead manually adapt andd >> perform those steps on the new apache/lucene and apache/solr repos. >> >> Jan >> >> 10. okt. 2021 kl. 13:45 skrev Mayya Sharipova : >> >> Hi Houston, >> Thank you for bringing this to my attention, I've corrected the 8.10.1 >> changelog for all the branches. >> >> Thanks a lot. >> >> On Fri, Oct 8, 2021 at 11:44 PM Houston Putman >> wrote: >> >>> Hey Mayya, >>> >>> I think there are some issues with the lucene changelog entries in >>> 8.10.1 across various branches (branch_8_10, branch_8x, and main). >>> I don't see LUCENE-10119, and LUCENE-10126 is marked as an 8.11.0 entry >>> in at least branch_8x. >>> >>> - Houston >>> >>> On Thu, Oct 7, 2021 at 9:32 PM Mayya Sharipova < >>> mayya.sharip...@elastic.co.invalid> wrote: >>> Hello everyone, I am now preparing for a bugfix release from branch branch_8_10 Please observe the normal rules for committing to this branch: * Before committing to the branch, reply to this thread and argue why the fix needs backporting and how long it will take. * All issues accepted for backporting should be marked with 8.10.1 in JIRA, and issues that should delay the release must be marked as Blocker * All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch. * Only Jira issues with Fix version 8.10.1 and priority "Blocker" will delay a release candidate build. - Currently we have the following committed for 8.10.1 LUCENE-10119: Do not set single sort with search after LUCENE-10126: Fix competitive iterator wrongly skip docs SOLR-15572: Fix a test failure caused by simplistic line parsing. SOLR-15665: Move polling logic under main - We have the following bug fixes already resolved in 8.11. Does anyone from the list below want to backport their fixes for 8.10.1 release as well? Please let me know by Monday * LUCENE-10110: MultiCollector now handles single leaf collector that wants to skip low-scoring hits but the combined score mode doesn't allow it. (Jim Ferenczi) * LUCENE-10111: Missing calculating the bytes used of DocsWithFieldSet in NormValuesWriter. (Lu Xugang) * LUCENE-10116: Missing calculating the bytes used of DocsWithFieldSetand currentValues in SortedSetDocValuesWriter. (Lu Xugang) * LUCENE-10070 Skip deleted docs when accumulating facet counts for all docs. (Ankur Goel, Greg Miller) * LUCENE-10134: ConcurrentSortedSetDocValuesFacetCounts shouldn't share liveDocs Bits across threads. (Ankur Goel) * SOLR-15626: Config-read permission does not allow access to /solr/admin/configs?action=LIST (Jon Senchyna) Thanks. >>
Re: Simplify the release artifacts
+1 overall, comments inline. On Mon, Oct 11, 2021 at 7:48 AM Dawid Weiss wrote: > > Hi. > > These are the thoughts that occurred to me while rewriting the > packaging in the build system. I think they're worth the discussion > because they could limit the size of the published artifacts as well > as their perceptive quality. > > 1. Who is going to use the lib/*.jar files we distribute in binary > releases? I don't think they are useful for anything. The dependency > information for modules is stored in maven POMs (and can be easily > written to text files, if it's really something people are dying to > preserve). +1 > > I don't think redistributing those JARs makes any sense other than to > make Luke work... What I would suggest is to remove third-party JARs > entirely from the binary distribution and have a separate binary > artifact with a fully functional top-level Luke application. > Alternatively, move those third-party JARs to the top-level > /thirdparty folder and Luke can access them from there. +1, I think there is already an issue open to give luke its own "release artifact" > > 2. Some of the *.txt files both at the top-level and inside subfolders > contain obsolete information. We should at least re-read these. My > personal opinion is that some of the README.txt files inside modules > have little practical use - their content should go inside the javadoc > (package level, perhaps) and this should be the only source of > documentation. +1, either nuke it, or fold it into javadoc, or at the very least rename to README.md > > 3. I would remove the "zip" binary distribution. I'm on Windows myself > so tgz is a tad more difficult to work with but Lucene is a library. > If somebody downloads a binary distribution they should know how to > unpack a tgz file (cygwin, total commander, whatever else). +1 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Simplify the release artifacts
Hi. These are the thoughts that occurred to me while rewriting the packaging in the build system. I think they're worth the discussion because they could limit the size of the published artifacts as well as their perceptive quality. 1. Who is going to use the lib/*.jar files we distribute in binary releases? I don't think they are useful for anything. The dependency information for modules is stored in maven POMs (and can be easily written to text files, if it's really something people are dying to preserve). I don't think redistributing those JARs makes any sense other than to make Luke work... What I would suggest is to remove third-party JARs entirely from the binary distribution and have a separate binary artifact with a fully functional top-level Luke application. Alternatively, move those third-party JARs to the top-level /thirdparty folder and Luke can access them from there. 2. Some of the *.txt files both at the top-level and inside subfolders contain obsolete information. We should at least re-read these. My personal opinion is that some of the README.txt files inside modules have little practical use - their content should go inside the javadoc (package level, perhaps) and this should be the only source of documentation. 3. I would remove the "zip" binary distribution. I'm on Windows myself so tgz is a tad more difficult to work with but Lucene is a library. If somebody downloads a binary distribution they should know how to unpack a tgz file (cygwin, total commander, whatever else). Thoughts? Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
