lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandre Rafalovitch (JIRA)" <>
Subject [jira] [Commented] (SOLR-5103) Plugin Improvements
Date Mon, 24 Nov 2014 16:34:13 GMT


Alexandre Rafalovitch commented on SOLR-5103:

bq. We don't yet have a uniform way to manage code+UI . To be honest , all UI is kind of an
afterthought in Solr

Well, it will continue being an afterthought if you continue not thinking about it. 

May I suggest a thought experiment? Let's imagine we are shipping Solr Javadoc as a plugin.
And it will be searchable (e.g. come with pre-built Solr collection). And the HTML itself
is - ideally - compressed and is served that way. Now, we can walk through the aspects required
to make it work. Maybe they will not all make it into 5, but the pieces that do line up should
be on the critical path of making a specific scenario happen.

The problem with plugins is that they seem easy but the real-life consequences of them get
hairy very fast. I think Solr desperately needs plugins, but they need to be a bit more than
a class in a jar. There needs to be some sort of management/flow/metadata to avoid fragmentation
and user confusion. Does not have to be super-comprehensive in initial setup, just with some
advance forethought.

> 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