apache/lucene-solr Is a Redirect: Where Lucene and Solr Live Now

What apache/lucene-solr Still Is, and What It Stopped Being

For years Lucene and Solr shipped from one tree: the library and the server, versioned together. The README at the top of this repository opens with a correction to that assumption. Solr has become a top-level Apache project, and main line development for both projects now happens in each project's own git repository. What remains here is a pointer, a licence, a PRs.md file and a branch.

The practical consequence is narrow but real. If you arrived expecting to find current Lucene or Solr source, you will not find it in the main line of this tree. The audience for this repository is small: people who need the 8.11.x bugfix branch, and people who followed an old link and need to be told where to go. The README does not describe a product. It describes a move.

The Split, the Two Repositories, and branch_8_11

The mechanism is a repository handoff, not a code change. Two git endpoints are named for ongoing work: apache/lucene for the library and apache/solr for the server. Bugfix development for 8.11.x releases stays on branch_8_11 in the shared repository, which is the only line of work the README says remains here.

That gives three destinations instead of one. Current Lucene work goes to the Lucene repository. Current Solr work goes to the Solr repository. Backported 8.11.x fixes go to branch_8_11 in this one. Nothing in the README suggests the shared tree receives new features, and nothing suggests branch_8_11 will ever carry anything beyond 8.11.x bugfixes. Treat the branch as a maintenance lane with a fixed version number attached to it.

For GitHub users the README is explicit that the gitbox repositories are not where pull requests go. It names two mirrors, github.com/apache/lucene and github.com/apache/solr, and says to clone the corresponding mirror and open pull requests against the main branch. Opening a pull request against a stale fork of the old combined tree is the failure mode this paragraph exists to prevent.

Installing and Building from the Correct Repository

This repository publishes no install instructions, no build command, no package name and no server configuration. The README gives repository URLs and nothing else, so the only honest first step is to clone the right tree. For current Lucene or Solr work, use the project repositories rather than this one.

git clone https://gitbox.apache.org/repos/asf/lucene.git
git clone https://gitbox.apache.org/repos/asf/solr.git

If you are using GitHub instead of gitbox, the README names the mirrors to clone and to target with pull requests.

git clone https://github.com/apache/lucene
git clone https://github.com/apache/solr

If your actual task is an 8.11.x bugfix, the README points at the shared repository and the branch that still carries that work.

git clone https://gitbox.apache.org/repos/asf/lucene-solr.git
cd lucene-solr
git checkout branch_8_11

After that checkout you are on the maintenance branch, not on a current release line. What you see next depends on the build files inside that branch, which the README does not document. Expect to read them yourself rather than follow a quickstart here.

Where This Repository Is the Wrong Tool

Anyone starting a new search project should not clone this repository. There is no main line development here, so a fresh checkout gives you either a pointer document or a branch frozen at the 8.11.x series. Building a new deployment on that branch means starting on a maintenance lane with no upstream feature path described in the README.

The second wrong use is subtler: treating this tree as a single project when deciding between a library and a server. Lucene and Solr are separate repositories now, with separate main branches and separate pull request targets. A team that plans to embed search in a Java application and a team that plans to run a search server are heading to two different clones. Choosing one because the old combined repository is the link you have is a decision made by URL, not by requirement.

The README is also silent on migration. It does not document how to move an existing checkout to the new repositories, how release artefacts are published, or what happens to the 8.11.x line after its last bugfix. If your plan depends on any of those, the README will not answer it.

Lucene or Solr, and How That Differs from Elasticsearch

The real alternative to this repository is not a competing product but the two repositories it now points at, and the choice between them is architectural. Lucene is the library: you embed it in a Java process and manage indexing, segments and search yourself. Solr is the server: it wraps that search capability behind an HTTP interface and runs as its own process, which is what most teams want when search is a service rather than a code path.

Elasticsearch is the comparison people reach for, and the split clarifies it. Elasticsearch is a server product built on Lucene, the same way Solr is a server built on Lucene. Choosing Solr over Elasticsearch is choosing between two servers over a shared library lineage, not choosing between a library and a server. That distinction matters here because this repository used to blur it: one tree, one version number, library and server side by side. The split makes the layering visible, and it makes the library option easier to see as a real choice rather than an implementation detail of the server.

Maintenance, Upgrades and the Apache-2.0 Licence

The last push to this repository was on 2026-05-15, which is recent enough that the tree is not abandoned, but the README frames its remaining role as 8.11.x bugfixes on branch_8_11 rather than general development. Do not read a recent push date as evidence that new features land here. The README says main line development happens elsewhere, and that statement governs how you should plan upgrades.

Upgrade cost follows from that. If you track branch_8_11, your upgrade path is bugfix releases within the 8.11.x series, and the README does not describe what comes after. If you want current work, your cost is a one-time move to the Lucene or Solr repository, plus whatever reconciliation your local patches need against a different tree. Plan for that move as a migration with its own review, not as a fetch.

The licence is Apache-2.0, stated in the repository metadata and in the header block at the top of the README, which reproduces the standard Apache License, Version 2.0 notice and points to the full text. Apache-2.0 is permissive and includes an explicit patent grant, but this is a description of what the files say, not legal advice. If you redistribute or modify the code, read the LICENSE and NOTICE files in the repository you actually build from, since that is now one of three trees.

Editorial conclusion

Adopt this repository only if you are maintaining or patching an 8.11.x deployment and need branch_8_11; everyone starting fresh should clone apache/lucene or apache/solr instead. Solr is now a top-level Apache project, so if you need a server with an HTTP API, the Solr repository is the one to read, and if you need a Java library to embed, read the Lucene repository. Verify first that the branch you intend to build still receives the fix you need, and check which repository your existing checkout actually points at before you open a pull request.

Frequently asked questions

Official sources

1. apache/lucene-solr on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README