= Plugins, Modules and Packages
:toc: left

This document discusses how developers can group features into Plugins, Modules and Packages.

== Definitions

=== Plugin

A plugin is a low level class that implements a certain Lucene or Solr interface, such as
`QParserPlugin`, `AuthPlugin`, `UpdateRequestProcessor`, `QueryResponseWriter` etc.
See ref guide page https://solr.apache.org/guide/solr/latest/configuration-guide/solr-plugins.html[Solr Plugins] for details.

=== Module

Solr Modules are addon Solr plugins that are not part of solr-core, but officially maintained
by the Solr project. They provide well-defined features such as the "extracting" module which lets
users index rich text documents with Apache Tika. Modules were earlier known as "contribs".

Each module produces a separate `.jar` file in the build, and additional dependencies required by each module are packaged with that module's `.jar` file. This helps keep the solr-core small and lean,
and also reduces risk by including only needed java classes and dependencies on the class-path.

A single module can contain multiple Plugins.

=== Package

A Package is a module or a 3rd party plugin for Solr provisioned with a `manifest.json`
to enable discovering and loading through https://solr.apache.org/guide/solr/latest/configuration-guide/package-manager.html[Solr's package manager]. Packages are loaded from a "package repository" which is
simply a json file on a HTTP server.

Packages can be maintained by 3rd party devs and hosted on
GitHub, like https://github.com/yasa-org/yasa[YASA],
https://github.com/rohitbemax/dataimporthandler[DataImportHandler],
https://github.com/erikhatcher/solr-velocity[Velocity],
https://github.com/cominvent/request-sanitizer-component[RequestSanitizerComponent]
and https://solr.cool/[several others]. Such packages are not endorsed by the Solr project.

The Solr project is also working on packaging our own (1st party) modules as packages,
and host them either inside the binary tarball distribution of Solr or later also in the
ASF download repos.

== Dev guide for creating modules

=== When to create a module

Any functionality added to Solr that is not obviously useful for all Solr users and that
spans more than a single source file, should be considered for a new module.

Solr functionality that requires risky dependencies can more easily be added as a module, because Solr users will not have to load those dependencies by default.

=== Module layout

Modules consist of a `solr-<moduleName>-X.Y.Z.jar` artifact as often also a set of dependency
`.jar` files that it needs to work (but not jars that are otherwise default a part of Solr).

Module sources live in the `solr/modules/` folder in the checkout, and have their own gradle
build file. See "Bootstrapping" paragraph on how to scaffold a new module.

The layout of modules in the binary distribution is produced by the gradle build and is
as follows:
```
<install-dir>/modules/<moduleName>/
  +-- README.md
  +-- lib/
      +-- solr-<moduleName>-X.Y.Z.jar
      +-- dependency-1.jar
      +-- other-dependency.jar
```

=== Bootstrapping a new module

It is not hard to create a new module. You can do it by hand, or you can run the helper tool:

```bash
dev-tools/scripts/scaffoldNewModule.py <short-name> <full name> <one line description>
```

Once you have the scaffold, start creating classes, or move out classes from solr-core.
Solr-core and test-framework are added as dependencies by default, and you can add custom
dependencies as necessary. Those will automatically end up in `<moduleName>/lib` in the
binary distro.

=== Module naming

As the number of modules grow, we should strive to keep naming logical. The proposal is to
structure module name as `<type>-<name>`.

Types can be:

* `analysis-` - for fieldTypes, tokenizers, token filters (lucene level)
* `update-` - for UpdateRequestHandlers, UpdateRequestProcessors and other indexing related
* `search-` - for QParser, ResponseWriters, SearchHandler, SearchComponent
* `auth-` - for Authentication and Autorization
* `backup-`- for backup repositories
* ...more here...

Examples:

* `search-clustering`
* `update-extraction`
* `backup-gcs`

== Dev guide for turning a module into a package

=== Adding a manifest

Create a file `<my-module>/src/main/resources/manifest.json`. It contents should be at a
minimum something like below:

```json
{
  "version-constraint": "9",
  "plugins": [
    {
      "name": "update-extraction",
      "setup-command": {
        "path": "/api/collections/${collection}/config",
        "payload": {"add-requesthandler": {"name": "${NAME}", "class": "update-extraction:org.apache.solr.handler.extraction.ExtractingRequestHandler"}},
        "method": "POST"
      },
      "uninstall-command": {
        "path": "/api/collections/${collection}/config",
        "payload": {"delete-requesthandler": "${NAME}"},
        "method": "POST"
      }
    }
  ],
  "parameter-defaults": {
    "NAME": "/update/extract"
  }
}
```

Version constraint must follow SemVer expression syntax, `9` means it is
compatible with any 9.x version of Solr. It is dangerous to assume compatibility with future versions, and for 1st party modules, we release them with every minor version, so consider
using e.g. `9.1`, which will be compatible with all bugfix 9.1 releases.

For details about how the package management internals work, please see
https://solr.apache.org/guide/solr/latest/configuration-guide/package-manager-internals.html[Package Manager Internals] chapter of the reference guide.