[
https://issues.apache.org/jira/browse/SOLR-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223110#comment-14223110
]
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: 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
