Apache Solr

A couple of weeks back, Apache Lucene Committer and PMC member, Michael McCandless started a discussion on factoring out a shared, standalone Analysis package for Lucene, Solr and Nutch. During the discussions, Yonik Seeley, Co-creator of Solr ... [More] , proposed merging the development of Lucene and Solr. After intense discussions and multiple rounds of voting, the following changes are being put into effect: Merging the developer mailing lists into a single list. Merging the set of committers. When any change is committed (to a module that “belongs to” Solr or to Lucene), all tests must pass. Release details will be decided by dev community, but, Lucene may release without Solr. Modularize the sources: pull things out of Lucene’s core (break out query parser, move all core queries & analyzers under their contrib counterparts), pull things out of Solr’s core (analyzers, queries). The following things do not change: Besides modularizing (above), the source code would remain factored into separate dirs/modules the way it is now. Issue tracking remains separate (SOLR-XXX and LUCENE-XXX issues). User’s lists remain separate. Web sites remain separate. Release artifacts/jars remain separate. So what does it mean for Lucene/Solr users? Nothing much, really. Except that you should see tighter co-ordination between Lucene and Solr development. New Lucene features should reach Solr faster and releases should be more frequent. Solr features may also be made available to Lucene users who do not want to setup Solr use the RESTy APIs. Already, Solr has been upgraded to use Lucene trunk (in branches/solr) and should soon become the new Solr trunk. There is talk of re-organizing the source structure to better fit the new model. Things are moving fast! Personally, I feel that this merge is a good thing for both Lucene and Solr: Solr users get the latest Lucene improvements faster and releases get streamlined. Lucene users get access to Solr features such as faceting. The in-sync trunk allows new features to make their way into the right place (Lucene vs Solr) more easily and duplication is minimized. Bugs are caught earlier by the huge combined test suite. More number of committers means more ideas and hands available to the projects Other Lucene based projects can benefit too because many Solr features will be made available through Java APIs. There are a couple of things to be worked out. For example, we need to decide where the integrated sources should live and whether or not to sync Solr’s version with Lucene’s. All this will take some time but I am confident that our combined community will manage the transition well. [Less]

A couple of weeks back, Apache Lucene Committer and PMC member, Michael McCandless started a discussion on factoring out a shared, standalone Analysis package for Lucene, Solr and Nutch. During the discussions, Yonik Seeley, Solr Creator, proposed ... [More] merging the development of Lucene and Solr. After intense discussions and multiple rounds of voting, the following changes are being put into effect: Merging the developer mailing lists into a single list. Merging the set of committers. When any change is committed (to a module that “belongs to” Solr or to Lucene), all tests must pass. Release details will be decided by dev community, but, Lucene may release without Solr. Modularize the sources: pull things out of Lucene’s core (break out query parser, move all core queries & analyzers under their contrib counterparts), pull things out of Solr’s core (analyzers, queries). The following things do not change: Besides modularizing (above), the source code would remain factored into separate dirs/modules the way it is now. Issue tracking remains separate (SOLR-XXX and LUCENE-XXX issues). User’s lists remain separate. Web sites remain separate. Release artifacts/jars remain separate. So what does it mean for Lucene/Solr users? Nothing much, really. Except that you should see tighter co-ordination between Lucene and Solr development. New Lucene features should reach Solr faster and releases should be more frequent. Solr features may also be made available to Lucene users who do not want to setup Solr use the RESTy APIs. Already, Solr has been upgraded to use Lucene trunk (in branches/solr) and should soon become the new Solr trunk. There is talk of re-organizing the source structure to better fit the new model. Things are moving fast! Personally, I feel that this merge is a good thing for both Lucene and Solr: Solr users get the latest Lucene improvements faster and releases get streamlined. Lucene users get access to Solr features such as faceting. The in-sync trunk allows new features to make their way into the right place (Lucene vs Solr) more easily and duplication is minimized. Bugs are caught earlier by the huge combined test suite. More number of committers means more ideas and hands available to the projects Other Lucene based projects can benefit too because many Solr features will be made available through Java APIs. There are a couple of things to be worked out. For example, we need to decide where the integrated sources should live and whether or not to sync Solr’s version with Lucene’s. All this will take some time but I am confident that our combined community will manage the transition well. [Less]

A couple of weeks back, Apache Lucene Committer and PMC member, Michael McCandless started a discussion on factoring out a shared, standalone Analysis package for Lucene, Solr and Nutch. During the discussions, Yonik Seeley, Solr Creator, proposed ... [More] merging the development of Lucene and Solr. After intense discussions and multiple rounds of voting, the following changes are being put into effect: Merging the developer mailing lists into a single list. Merging the set of committers. When any change is committed (to a module that “belongs to” Solr or to Lucene), all tests must pass. Release details will be decided by dev community, but, Lucene may release without Solr. Modularize the sources: pull things out of Lucene’s core (break out query parser, move all core queries & analyzers under their contrib counterparts), pull things out of Solr’s core (analyzers, queries). The following things do not change: Besides modularizing (above), the source code would remain factored into separate dirs/modules the way it is now. Issue tracking remains separate (SOLR-XXX and LUCENE-XXX issues). User’s lists remain separate. Web sites remain separate. Release artifacts/jars remain separate. So what does it mean for Lucene/Solr users? Nothing much, really. Except that you should see tighter co-ordination between Lucene and Solr development. New Lucene features should reach Solr faster and releases should be more frequent. Solr features may also be made available to Lucene users who do not want to setup Solr use the RESTy APIs. Already, Solr has been upgraded to use Lucene trunk (in branches/solr) and should soon become the new Solr trunk. There is talk of re-organizing the source structure to better fit the new model. Things are moving fast! Personally, I feel that this merge is a good thing for both Lucene and Solr: Solr users get the latest Lucene improvements faster and releases get streamlined. Lucene users get access to Solr features such as faceting. The in-sync trunk allows new features to make their way into the right place (Lucene vs Solr) more easily and duplication is minimized. Bugs are caught earlier by the huge combined test suite. More number of committers means more ideas and hands available to the projects Other Lucene based projects can benefit too because many Solr features will be made available through Java APIs. There are a couple of things to be worked out. For example, we need to decide where the integrated sources should live and whether or not to sync Solr’s version with Lucene’s. All this will take some time but I am confident that our combined community will manage the transition well. [Less]

A couple of weeks back, Apache Lucene Committer and PMC member, Michael McCandless started a discussion on factoring out a shared, standalone Analysis package for Lucene, Solr and Nutch. During the discussions, Yonik Seeley, Solr Creator, proposed ... [More] merging the development of Lucene and Solr. After intense discussions and multiple rounds of voting, the following changes are being put into effect: Merging the developer mailing lists into a single list. Merging the set of committers. When any change is committed (to a module that “belongs to” Solr or to Lucene), all tests must pass. Release details will be decided by dev community, but, Lucene may release without Solr. Modularize the sources: pull things out of Lucene’s core (break out query parser, move all core queries & analyzers under their contrib counterparts), pull things out of Solr’s core (analyzers, queries). The following things do not change: Besides modularizing (above), the source code would remain factored into separate dirs/modules the way it is now. Issue tracking remains separate (SOLR-XXX and LUCENE-XXX issues). User’s lists remain separate. Web sites remain separate. Release artifacts/jars remain separate. So what does it mean for Lucene/Solr users? Nothing much, really. Except that you should see tighter co-ordination between Lucene and Solr development. New Lucene features should reach Solr faster and releases should be more frequent. Solr features may also be made available to Lucene users who do not want to setup Solr use the RESTy APIs. Already, Solr has been upgraded to use Lucene trunk (in branches/solr) and should soon become the new Solr trunk. There is talk of re-organizing the source structure to better fit the new model. Things are moving fast! Personally, I feel that this merge is a good thing for both Lucene and Solr: Solr users get the latest Lucene improvements faster and releases get streamlined. Lucene users get access to Solr features such as faceting. The in-sync trunk allows new features to make their way into the right place (Lucene vs Solr) more easily and duplication is minimized. Bugs are caught earlier by the huge combined test suite. More number of committers means more ideas and hands available to the projects Other Lucene based projects can benefit too because many Solr features will be made available through Java APIs. There are a couple of things to be worked out. For example, we need to decide where the integrated sources should live and whether or not to sync Solr’s version with Lucene’s. All this will take some time but I am confident that our combined community will manage the transition well. [Less]

Congratulations to the Apache Lucene team on releasing Lucene Java 3.0.1 and 2.9.2. Both of these are bug fix releases and are backwards compatible with Lucene Java 3.0.0 and 2.9.1 respectively. From the official announcement: Hello Lucene users ... [More] , On behalf of the Lucene development community I would like to announce the release of Lucene Java versions 3.0.1 and 2.9.2: Both releases fix bugs in the previous versions: 2.9.2 is a bugfix release for the Lucene Java 2.x series, based on Java 1.4 3.0.1 has the same bug fix level but is for the Lucene Java 3.x series, based on Java 5 New users of Lucene are advised to use version 3.0.1 for new developments, because it has a clean, type-safe API. Important improvements in these releases include: An increased maximum number of unique terms in each index segment. Fixed experimental CustomScoreQuery to respect per-segment search. This introduced an API change! Important fixes to IndexWriter: a commit() thread-safety issue, lost document deletes in near real-time indexing. Bugfixes for Contrib’s Analyzers package. Restoration of some public methods that were lost during deprecation removal. The new Attribute-based TokenStream API now works correctly with different class loaders. Both releases are fully compatible with the corresponding previous versions. We strongly recommend upgrading to 2.9.2 if you are using 2.9.1 or 2.9.0; and to 3.0.1 if you are using 3.0.0. See core changes at: http://lucene.apache.org/java/3_0_1/changes/Changes.html http://lucene.apache.org/java/2_9_2/changes/Changes.html and contrib changes at: http://lucene.apache.org/java/3_0_1/changes/Contrib-Changes.html http://lucene.apache.org/java/2_9_2/changes/Contrib-Changes.html Binary and source distributions are available at http://www.apache.org/dyn/closer.cgi/lucene/java/ Lucene artifacts are also available in the Maven2 repository at http://repo1.maven.org/maven2/org/apache/lucene/ [Less]

Congratulations to the Apache Lucene team on releasing Lucene Java 3.0.1 and 2.9.2. Both of these are bug fix releases and are backwards compatible with Lucene Java 3.0.0 and 2.9.1 respectively. From the official announcement: Hello Lucene ... [More] users, On behalf of the Lucene development community I would like to announce the release of Lucene Java versions 3.0.1 and 2.9.2: Both releases fix bugs in the previous versions: 2.9.2 is a bugfix release for the Lucene Java 2.x series, based on Java 1.4 3.0.1 has the same bug fix level but is for the Lucene Java 3.x series, based on Java 5 New users of Lucene are advised to use version 3.0.1 for new developments, because it has a clean, type-safe API. Important improvements in these releases include: An increased maximum number of unique terms in each index segment. Fixed experimental CustomScoreQuery to respect per-segment search. This introduced an API change! Important fixes to IndexWriter: a commit() thread-safety issue, lost document deletes in near real-time indexing. Bugfixes for Contrib’s Analyzers package. Restoration of some public methods that were lost during deprecation removal. The new Attribute-based TokenStream API now works correctly with different class loaders. Both releases are fully compatible with the corresponding previous versions. We strongly recommend upgrading to 2.9.2 if you are using 2.9.1 or 2.9.0; and to 3.0.1 if you are using 3.0.0. See core changes at: http://lucene.apache.org/java/3_0_1/changes/Changes.html http://lucene.apache.org/java/2_9_2/changes/Changes.html and contrib changes at: http://lucene.apache.org/java/3_0_1/changes/Contrib-Changes.html http://lucene.apache.org/java/2_9_2/changes/Contrib-Changes.html Binary and source distributions are available at http://www.apache.org/dyn/closer.cgi/lucene/java/ Lucene artifacts are also available in the Maven2 repository at http://repo1.maven.org/maven2/org/apache/lucene/ [Less]

Congratulations to the Apache Lucene team on releasing Lucene Java 3.0.1 and 2.9.2. Both of these are bug fix releases and are backwards compatible with Lucene Java 3.0.0 and 2.9.1 respectively. From the official announcement: Hello Lucene users ... [More] , On behalf of the Lucene development community I would like to announce the release of Lucene Java versions 3.0.1 and 2.9.2: Both releases fix bugs in the previous versions: 2.9.2 is a bugfix release for the Lucene Java 2.x series, based on Java 1.4 3.0.1 has the same bug fix level but is for the Lucene Java 3.x series, based on Java 5 New users of Lucene are advised to use version 3.0.1 for new developments, because it has a clean, type-safe API. Important improvements in these releases include: An increased maximum number of unique terms in each index segment. Fixed experimental CustomScoreQuery to respect per-segment search. This introduced an API change! Important fixes to IndexWriter: a commit() thread-safety issue, lost document deletes in near real-time indexing. Bugfixes for Contrib’s Analyzers package. Restoration of some public methods that were lost during deprecation removal. The new Attribute-based TokenStream API now works correctly with different class loaders. Both releases are fully compatible with the corresponding previous versions. We strongly recommend upgrading to 2.9.2 if you are using 2.9.1 or 2.9.0; and to 3.0.1 if you are using 3.0.0. See core changes at: http://lucene.apache.org/java/3_0_1/changes/Changes.html http://lucene.apache.org/java/2_9_2/changes/Changes.html and contrib changes at: http://lucene.apache.org/java/3_0_1/changes/Contrib-Changes.html http://lucene.apache.org/java/2_9_2/changes/Contrib-Changes.html Binary and source distributions are available at http://www.apache.org/dyn/closer.cgi/lucene/java/ Lucene artifacts are also available in the Maven2 repository at http://repo1.maven.org/maven2/org/apache/lucene/ [Less]

Congratulations to the Apache Lucene team on releasing Lucene Java 3.0.1 and 2.9.2. Both of these are bug fix releases and are backwards compatible with Lucene Java 3.0.0 and 2.9.1 respectively. From the official announcement: Hello Lucene ... [More] users, On behalf of the Lucene development community I would like to announce the release of Lucene Java versions 3.0.1 and 2.9.2: Both releases fix bugs in the previous versions: 2.9.2 is a bugfix release for the Lucene Java 2.x series, based on Java 1.4 3.0.1 has the same bug fix level but is for the Lucene Java 3.x series, based on Java 5 New users of Lucene are advised to use version 3.0.1 for new developments, because it has a clean, type-safe API. Important improvements in these releases include: An increased maximum number of unique terms in each index segment. Fixed experimental CustomScoreQuery to respect per-segment search. This introduced an API change! Important fixes to IndexWriter: a commit() thread-safety issue, lost document deletes in near real-time indexing. Bugfixes for Contrib’s Analyzers package. Restoration of some public methods that were lost during deprecation removal. The new Attribute-based TokenStream API now works correctly with different class loaders. Both releases are fully compatible with the corresponding previous versions. We strongly recommend upgrading to 2.9.2 if you are using 2.9.1 or 2.9.0; and to 3.0.1 if you are using 3.0.0. See core changes at: http://lucene.apache.org/java/3_0_1/changes/Changes.html http://lucene.apache.org/java/2_9_2/changes/Changes.html and contrib changes at: http://lucene.apache.org/java/3_0_1/changes/Contrib-Changes.html http://lucene.apache.org/java/2_9_2/changes/Contrib-Changes.html Binary and source distributions are available at http://www.apache.org/dyn/closer.cgi/lucene/java/ Lucene artifacts are also available in the Maven2 repository at http://repo1.maven.org/maven2/org/apache/lucene/ [Less]

According to a blog post from Microsoft Distinguished Engineer and CTO, FAST Bjørn Olstad, the 2010 products will be the last to have a search core that runs on Linux and UNIX. Being involved in Apache Solr and the newly formed Lucene Connectors ... [More] Framework (LCF) project, I’m very interested in the implications. Undoubtedly, at least some FAST customers will not be happy with this decision and will want to switch to something which can still run on Linux/UNIX. I believe that this is a great opportunity for the Apache Solr/LCF combo. Perhaps, the newly proposed Apache Spatial Information Systems (SIS) will help as well. Of course, this is big news for Lucid Imagination, Sematext and other companies as well who offer consultancy, training and support for Lucene/Solr. I’d like to ask people who have used FAST in the past, what would it take for Lucene/Solr/LCF to fill the gap? [Less]

According to a blog post from Microsoft Distinguished Engineer and CTO, FAST Bjørn Olstad, the 2010 products will be the last to have a search core that runs on Linux and UNIX. Being involved in Apache Solr and the newly formed Lucene Connectors ... [More] Framework (LCF) project, I’m very interested in the implications. Undoubtedly, at least some FAST customers will not be happy with this decision and will want to switch to something which can still run on Linux/UNIX. I believe that this is a great opportunity for the Apache Solr/LCF combo. Perhaps, the newly proposed Apache Spatial Information Systems (SIS) will help as well. Of course, this is big news for Lucid Imagination, Sematext and other companies as well who offer consultancy, training and support for Lucene/Solr. I’d like to ask people who have used FAST in the past, what would it take for Lucene/Solr/LCF to fill the gap? [Less]