lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl (JIRA) <>
Subject [jira] [Commented] (SOLR-5103) Plugin Improvements
Date Thu, 20 Aug 2015 08:00:52 GMT


Jan Høydahl commented on SOLR-5103:

bq. What happens if a plugin project uses one of the same dependent jars as Solr, but packages
a wildly different version than the version we package?

I think we don't need to re-invent OSGI to get a better plugin regime for Solr. We can document
simple requirements for developers to follow.
* Never include libraries or classes that is already part of core Lucene/Solr
* In your {{}}, list the Solr version(s) that the plugin is tested with
(and our tooling could require a {{--force}} option to disregard this and install anyway)
* etc

In the first version we can then simply add all jars in the plugin's {{/lib}} folder to classloader.
Then if a future version of Solr causes trouble for an older plugin, the plugin maintainer
must release a compatible update. When it comes to clashes between different 3rd party plugins
we can tackle that with more advanced measures when it happens, or plugin developers could
treat such cases as bugs and provide a fix themselves. For now let's keep it simple.

> Plugin Improvements
> -------------------
>                 Key: SOLR-5103
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Grant Ingersoll
>            Assignee: Grant Ingersoll
>             Fix For: Trunk
> I think for 5.0, we should make it easier to add plugins by defining a plugin package,
ala a Hadoop Job jar, which is a self--contained archive of a plugin that can be easily installed
(even from the UI!) and configured programmatically.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message