lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl (JIRA) <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-5103) Plugin Improvements
Date Wed, 19 Aug 2015 13:26:46 GMT

    [ https://issues.apache.org/jira/browse/SOLR-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14702985#comment-14702985
] 

Jan Høydahl edited comment on SOLR-5103 at 8/19/15 1:26 PM:
------------------------------------------------------------

bq. I think that's a little more to a plugin than upload mechanics. There is a need for meta-data
convention, dependency handling, versioning, etc. Supplementary UI.

Totally agree. But we need to start in one end. Perhaps defining the minimum zip/jar layout
for what to constitute a plugin. What if we choose our own file ending, e.g. {{.solrplugin}}
which is really just a zip file. Then a possible layout could be
{noformat}
my-plugin.solrplugin
/solrplugin.properties -- defining e.g. name, version, dependencies etc
/lib/  (jars to be added to classpath)
/config/config-api-commands.json  (a series of commands to be run towards config API)
/config/schema-api-commands.json  (a series of commands to be run towards config API)
{noformat}

Then, over time, we can evolve the spec and add support for pluggable UI etc.

There are tons of questions to address too
* Size limitation in blob store?
* Should Solr unpack all libs from the {{.solrplugin}} pkg and add them individually to blob
store, or write a classloader that adds everything directly from the zip?
* What about version clash of dependencies - should not jeopardize the rest of the system
* Should a plugin be allowed to depend on another plugin, i.e. fail install unless the other
plugin is installed?
* Should all plugins be system-level, and then require a new config-API {{/collection/config
"install-plugin"}} command to enable it for each collection?
* What about system-level plugins, such as Authentication and Authorization plugins? Should
{{security.json}} be auto updated when installing an auth plugin, or only if it does not exist
already?
* There should be a way to install plugins without registering the component with APIs, e.g.
{{bin/solr installplugin solrcell -noregister}}
* Uninstall of a plugin - it should also be able to unregister things from config / schema,
for all collections where it is enabled (scary)

First step is to see if there is enough committer interest in going down this path, then split
things up into many smaller tasks that can be handled separately.


was (Author: janhoy):
bq. I think that's a little more to a plugin than upload mechanics. There is a need for meta-data
convention, dependency handling, versioning, etc. Supplementary UI.

Totally agree. But we need to start in one end. Perhaps defining the minimum zip/jar layout
for what to constitute a plugin. What if we choose our own file ending, e.g. {.solrplugin}
which is really just a zip file. Then a possible layout could be
{noformat}
my-plugin.solrplugin
/solrplugin.properties -- defining e.g. name, version, dependencies etc
/lib/  (jars to be added to classpath)
/config/config-api-commands.json  (a series of commands to be run towards config API)
/config/schema-api-commands.json  (a series of commands to be run towards config API)
{noformat}

Then, over time, we can evolve the spec and add support for pluggable UI etc.

There are tons of questions to address too
* Size limitation in blob store?
* Should Solr unpack all libs from the {{.solrplugin}} pkg and add them individually to blob
store, or write a classloader that adds everything directly from the zip?
* What about version clash of dependencies - should not jeopardize the rest of the system
* Should all plugins be system-level, and then require a new {{/collection/config "install-plugin"}}
command to enable it for each collection?
* What about system-level plugins, such as Authentication and Authorization plugins? Should
{{security.json}} be auto updated when installing an auth plugin, or only if it does not exist
already?
* There should be a way to install plugins without registering the component with APIs, e.g.
{{bin/solr installplugin solrcell -noregister}}
* Uninstall of a plugin - it should also be able to unregister things from config / schema,
for all collections where it is enabled (scary)

First step is to see if there is enough committer interest in going down this path, then split
things up into many smaller tasks that can be handled separately.

> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message