[
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: [email protected]
For additional commands, e-mail: [email protected]
