[
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089104#comment-17089104
]
David Smiley commented on SOLR-14414:
-------------------------------------
[~marcussorealheis], we (the Solr project) find that we don't have enough
helpers maintaining Solr relative to the amount of code. Solr is a beast.
There are different means to tackle this...
One way I'm chipping in is by deprecating / removing old things in Solr that
have newer replacements that have been out for awhile (e.g. some spatial stuff
or some old highlighter) -- SOLR-13138. Another example requiring much more
work are refactorings resulting in the removal of the old Filter class --
SOLR-12336. These aren't that significant given the scale of the situation,
and those are examples of old/outdated things.
Another take on the problem is splitting out functionality from the project
into external projects delivering packages with plugins that can be composed
back into Solr easily. The new package system Noble/Ishan spearheaded is a
huge boon to the project for multiple reasons, but pertinent here is that it
provides infrastructure to more properly support plugins living external to
Solr. We've already identified some contrib modules like the DIH and Velocity
will be pushed out to external projects in this way.
I think we want to do the same thing for Solr's UI -- move it out of the
codebase, for reasons already stated, well said by Ishan I think. Unlike the
DIH or Velocity, however, Solr truly ought to ship with this because we all
recognize how valuable the UI is. This is not incompatible -- Solr could come
with a "package" and even pre-install it so that it's running just like the
current one does. Also, we must recognize it's early days for this new system,
and I don't think today it supports an admin UI sort of plugin. I think Ishan
volunteered to help fill that gap? Let's stipulate there either is no gap or
it gets filled, and furthermore you get whatever help is needed in being able
to do this.
> New Admin UI
> ------------
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
> Affects Versions: master (9.0)
> Reporter: Marcus Eagan
> Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build
> a modern UI that is both more security and does not depend on deprecated, end
> of life code. In this ticket, I intend to familiarize the community with the
> efforts of the community to do just that that. While we are nearing feature
> parity, but not there yet as many have suggested we could complete this task
> in iterations, here is an attempt to get the ball rolling. I have mostly
> worked on it in weekend nights on the occasion that I could find the time.
> Angular is certainly not my specialty, and this is my first attempt at using
> TypeScript besides a few brief learning exercises here and there. However, I
> will be engaging experts in both of these areas for consultation as our
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be
> rewritten, and there are even at least three essential components to the app
> missing, along with some tests. A couple other things missing are the V2 API,
> which I found difficult to build with in this context because it is not
> documented on the web. I understand that it is "self-documenting," but the
> most easy-to-use APIs are still documented on the web. Maybe it is entirely
> documented on the web, and I had trouble finding it. Forgive me, as that
> could be an area of assistance. Another area where I need assistance is
> packaging this application as a Solr package. I understand this app is not in
> the right place for that today, but it can be. There are still many
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now. It
> can quickly be modified to start as a part of the typical start commands as
> it approaches parity. I expect there will be a lot of opinions. I welcome
> them, of course. The community input should drive the project's success.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
