[
https://issues.apache.org/jira/browse/SOLR-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14704464#comment-14704464
]
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 {{solrplugin.properties}}, 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: https://issues.apache.org/jira/browse/SOLR-5103
> 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
