Solr
  1. Solr
  2. SOLR-5507

Admin UI - Refactoring using AngularJS

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.1, 6.0
    • Component/s: web gui
    • Labels:
      None

      Description

      On the LSR in Dublin, i've talked again to Upayavira and this time we talked about Refactoring the existing UI - using AngularJS: providing (more, internal) structure and what not ;>

      He already started working on the Refactoring, so this is more a 'tracking' issue about the progress he/we do there.

      Will extend this issue with a bit more context & additional information, w/ thoughts about the possible integration in the existing UI and more (:

      1. SOLR5507.patch
        1.47 MB
        Erick Erickson
      2. SOLR5507.patch
        1.46 MB
        Erick Erickson
      3. SOLR5507.patch
        1.46 MB
        Upayavira
      4. SOLR5507.patch
        1.43 MB
        Upayavira
      5. SOLR5507.patch
        1.17 MB
        Upayavira
      6. SOLR5507.patch
        1.13 MB
        Upayavira
      7. SOLR-5507.patch
        1.94 MB
        Erick Erickson
      8. SOLR-5507.patch
        923 kB
        Upayavira
      9. SOLR5507.patch.gz
        483 kB
        Upayavira
      10. SOLR5507.patch.gz
        423 kB
        Upayavira

        Issue Links

          Activity

          Hide
          Upayavira added a comment -

          I have experimented with a simple clean rewrite, code visible here: https://github.com/upayavira/lucene-solr/tree/trunk
          or more particularly here: https://github.com/upayavira/lucene-solr/tree/trunk/solr/webapp/web

          This has proven, to me at least, that an AngularJS based admin UI could be much cleaner, more concise, and easier to maintain.

          Now, we are exploring how we might transition from a Sammy based UI to an Angular based one, as the option of a complete rewrite followed by a swap-out really isn't practical. Thus, we'd need the ability somehow to run Sammy and Angular side-by-side for a while, implement new stuff using Angular, and gradually port over existing functionality to Angular as and when.

          Show
          Upayavira added a comment - I have experimented with a simple clean rewrite, code visible here: https://github.com/upayavira/lucene-solr/tree/trunk or more particularly here: https://github.com/upayavira/lucene-solr/tree/trunk/solr/webapp/web This has proven, to me at least, that an AngularJS based admin UI could be much cleaner, more concise, and easier to maintain. Now, we are exploring how we might transition from a Sammy based UI to an Angular based one, as the option of a complete rewrite followed by a swap-out really isn't practical. Thus, we'd need the ability somehow to run Sammy and Angular side-by-side for a while, implement new stuff using Angular, and gradually port over existing functionality to Angular as and when.
          Hide
          Grant Ingersoll added a comment -

          +1, I have been thinking the same thing lately, as I found extending the current UI to be pretty hard to do when I added doc additions.

          Upayavira, might be nice to put up a patch, if you can.

          Show
          Grant Ingersoll added a comment - +1, I have been thinking the same thing lately, as I found extending the current UI to be pretty hard to do when I added doc additions. Upayavira, might be nice to put up a patch, if you can.
          Hide
          Grant Ingersoll added a comment -

          One of the things I would really love to see is the ability to plug in/inject new UI components. Imagine if we had a plugin framework that could ship the back-end functionality as well as the admin piece. After the plugin gets installed and registered, the admin piece slots in automatically.

          Show
          Grant Ingersoll added a comment - One of the things I would really love to see is the ability to plug in/inject new UI components. Imagine if we had a plugin framework that could ship the back-end functionality as well as the admin piece. After the plugin gets installed and registered, the admin piece slots in automatically.
          Hide
          Upayavira added a comment -

          I have a prototype of a complete rewrite, that shows the technology can create clean code even on something as complex as the analysis pane.

          However, I'm stalled on the topic of how to manage a transition between the two technologies, without requiring a hard-switch between them, as that would likely be way too tough to manage.

          So, we need to work out a way for the two technologies to play nicely together as an intermediate step - that's what I'm grappling with right now.

          Show
          Upayavira added a comment - I have a prototype of a complete rewrite, that shows the technology can create clean code even on something as complex as the analysis pane. However, I'm stalled on the topic of how to manage a transition between the two technologies, without requiring a hard-switch between them, as that would likely be way too tough to manage. So, we need to work out a way for the two technologies to play nicely together as an intermediate step - that's what I'm grappling with right now.
          Hide
          Yago Riveiro added a comment -

          Upayavira, What are the reasons for keeping the two UIs working together?

          I understand that rewrite the whole UI is a epic task, but the time that we will spend thinking and implementing a way to have the new and the old UI working together can be used to finish the new and release it with a new release of Solr.

          Also, in this transition, we will generate (most probably) new bugs and artefacts. With a point of time where we switch between both, all bugs will be about new UI.

          Show
          Yago Riveiro added a comment - Upayavira , What are the reasons for keeping the two UIs working together? I understand that rewrite the whole UI is a epic task, but the time that we will spend thinking and implementing a way to have the new and the old UI working together can be used to finish the new and release it with a new release of Solr. Also, in this transition, we will generate (most probably) new bugs and artefacts. With a point of time where we switch between both, all bugs will be about new UI.
          Hide
          Grant Ingersoll added a comment -

          I see know reason to keep them working together. Do the new UI on trunk, leave the existing one on 4.x. We have no back compat requirements for UI, AFAIK.

          Show
          Grant Ingersoll added a comment - I see know reason to keep them working together. Do the new UI on trunk, leave the existing one on 4.x. We have no back compat requirements for UI, AFAIK.
          Hide
          Upayavira added a comment -

          There is a lot of code there. I have limited volunteer time. I could imagine it taking 3-6mths to get through it all. Open source development works best if the work can be done piecemeal, so we need to find a way to facilitate that, rather than getting 3/4 of the way through a 6mth project which then stalls through lack of developer time.

          Personally, I think this would be a fun project, that would benefit Solr. I'd love to see us find a way to make it happen.

          Show
          Upayavira added a comment - There is a lot of code there. I have limited volunteer time. I could imagine it taking 3-6mths to get through it all. Open source development works best if the work can be done piecemeal, so we need to find a way to facilitate that, rather than getting 3/4 of the way through a 6mth project which then stalls through lack of developer time. Personally, I think this would be a fun project, that would benefit Solr. I'd love to see us find a way to make it happen.
          Hide
          Upayavira added a comment -

          The best way to keep something in development is to have something that is usable most of the time. If we crack that, then the transition between old and new is a set of simpler, small manageable steps, rather than a major project requiring planning/etc.

          Show
          Upayavira added a comment - The best way to keep something in development is to have something that is usable most of the time. If we crack that, then the transition between old and new is a set of simpler, small manageable steps, rather than a major project requiring planning/etc.
          Hide
          Yago Riveiro added a comment -

          Ok, seems a valid argument .

          If you release de code and some guide line about the architecture of the new UI, we can work in this new feature and see it in Solr soon.

          Show
          Yago Riveiro added a comment - Ok, seems a valid argument . If you release de code and some guide line about the architecture of the new UI, we can work in this new feature and see it in Solr soon.
          Hide
          Upayavira added a comment -

          I'll try to put some time aside this weekend to mess further. Either with a concurrent Sammy/Angular, or a pure Angular trunk version (which I've got going already, in a hacky way).

          Show
          Upayavira added a comment - I'll try to put some time aside this weekend to mess further. Either with a concurrent Sammy/Angular, or a pure Angular trunk version (which I've got going already, in a hacky way).
          Hide
          Hoss Man added a comment -

          I see know reason to keep them working together. Do the new UI on trunk, leave the existing one on 4.x. We have no back compat requirements for UI, AFAIK.

          But the best way to help find bugs in the new UI, and to encourage people to help add features, is to get it in the hands of users in releases.

          What we did with the current UI during the 3.x/4.x time frame was to have both UI code bases going under diff paths – the old JSP based UI used "/admin" while the new UI just used "/" ... you could do the same thing with an angular based UI, pick any path (maybe even "/experimental_ui" and anchor the new work there - commit to both trunk and the 4x branch, and start publicizing it to new users even in the 4.x releases. if it takes off, and people like it then we eventually update trunk to mv "/experimental_ui" to "/" and remove the current stuff

          Show
          Hoss Man added a comment - I see know reason to keep them working together. Do the new UI on trunk, leave the existing one on 4.x. We have no back compat requirements for UI, AFAIK. But the best way to help find bugs in the new UI, and to encourage people to help add features, is to get it in the hands of users in releases. What we did with the current UI during the 3.x/4.x time frame was to have both UI code bases going under diff paths – the old JSP based UI used "/admin" while the new UI just used "/" ... you could do the same thing with an angular based UI, pick any path (maybe even "/experimental_ui" and anchor the new work there - commit to both trunk and the 4x branch, and start publicizing it to new users even in the 4.x releases. if it takes off, and people like it then we eventually update trunk to mv "/experimental_ui" to "/" and remove the current stuff
          Hide
          Upayavira added a comment -

          Hoss - that could work - so long as folks do new feature development on both, or on the new one only. I'll try and come up with a patch to get this started.

          Show
          Upayavira added a comment - Hoss - that could work - so long as folks do new feature development on both, or on the new one only. I'll try and come up with a patch to get this started.
          Hide
          Kranti Parisa added a comment -

          This is cool. I was thinking on the same stuff.

          It would be awesome to add a section on the Admin UI to display the CUSTOM INSTANCE INFO.
          For example

          Instance: INDEXER
          Version/Release Number: 1.0.1
          and more..

          These values could be read from solrconfig.xml or so. Solr could be installed as INDEXER (Master) and QUERYENGINE (Slave) on different data centers with different versions in a typical production environment.

          It would be nice to have a facility to write some custom info into solrconfig.xml or so during the installation and that can be displayed right on the Solr Admin UI.

          Show
          Kranti Parisa added a comment - This is cool. I was thinking on the same stuff. It would be awesome to add a section on the Admin UI to display the CUSTOM INSTANCE INFO. For example Instance: INDEXER Version/Release Number: 1.0.1 and more.. These values could be read from solrconfig.xml or so. Solr could be installed as INDEXER (Master) and QUERYENGINE (Slave) on different data centers with different versions in a typical production environment. It would be nice to have a facility to write some custom info into solrconfig.xml or so during the installation and that can be displayed right on the Solr Admin UI.
          Hide
          Otis Gospodnetic added a comment -

          One of the things I would really love to see is the ability to plug in/inject new UI components. Imagine if we had a plugin framework that could ship the back-end functionality as well as the admin piece. After the plugin gets installed and registered, the admin piece slots in automatically.

          Similar to this, if this new admin UI lent itself to people packaging different things with Solr and having information about them easily exposed in the admin UI, that may result in livelier ecosystem around Solr.

          Show
          Otis Gospodnetic added a comment - One of the things I would really love to see is the ability to plug in/inject new UI components. Imagine if we had a plugin framework that could ship the back-end functionality as well as the admin piece. After the plugin gets installed and registered, the admin piece slots in automatically. Similar to this, if this new admin UI lent itself to people packaging different things with Solr and having information about them easily exposed in the admin UI, that may result in livelier ecosystem around Solr.
          Hide
          Upayavira added a comment -

          i.e. allow some of the JS etc to be defined in solrconfig or equivalent, allowing for more natural extension points. Interesting idea.

          And here's one to annoy Stefan. I'd really like to see if we can use Bootstrap. That is, overlay Stefan's visuals on top of a Bootstrap (or Bootstrap style) CSS. This, in my view, would also make it much easier for non-visual devs to make decent UI components by just copying stuff that already works.

          Show
          Upayavira added a comment - i.e. allow some of the JS etc to be defined in solrconfig or equivalent, allowing for more natural extension points. Interesting idea. And here's one to annoy Stefan. I'd really like to see if we can use Bootstrap. That is, overlay Stefan's visuals on top of a Bootstrap (or Bootstrap style) CSS. This, in my view, would also make it much easier for non-visual devs to make decent UI components by just copying stuff that already works.
          Hide
          Yago Riveiro added a comment - - edited

          +1 for use bootstrap.

          With an UI tool library with components to use "as is" and a plugin system, we will see a lot of new stuff inside the UI and this is good for the community.

          Show
          Yago Riveiro added a comment - - edited +1 for use bootstrap. With an UI tool library with components to use "as is" and a plugin system, we will see a lot of new stuff inside the UI and this is good for the community.
          Hide
          Kranti Parisa added a comment -

          +1 for plugin/component capabilities. That would bring in lot of creativity and many useful features.

          Show
          Kranti Parisa added a comment - +1 for plugin/component capabilities. That would bring in lot of creativity and many useful features.
          Hide
          Erik Hatcher added a comment -

          Just for the record, the VelocityResponseWriter has always supported templates coming from the "resource loader", meaning that templates can be packaged into plugin .jar files and they are then accessible by name using the v.template parameter. The idea was to allow 3rd party plugins to ship with UI as well as behavior.

          Show
          Erik Hatcher added a comment - Just for the record, the VelocityResponseWriter has always supported templates coming from the "resource loader", meaning that templates can be packaged into plugin .jar files and they are then accessible by name using the v.template parameter. The idea was to allow 3rd party plugins to ship with UI as well as behavior.
          Hide
          Upayavira added a comment -

          First pass. This patch works alongside the existing UI. It:

          • brings in a basic Angular framework
          • enables the 'cores' menu
          • starts getting the main 'index' page infrastructure ready.

          A lot more to come, but hopefully this gives folks an idea of what it might look like.

          I imagine at the point where we scrap the old one and switch, we'll move all the files out of angular directories to one level up.

          My next task is to get the index page actually working correctly. The work involved is really understanding what all the necessary parts are on the existing page, and porting it over to the new framework.

          Show
          Upayavira added a comment - First pass. This patch works alongside the existing UI. It: brings in a basic Angular framework enables the 'cores' menu starts getting the main 'index' page infrastructure ready. A lot more to come, but hopefully this gives folks an idea of what it might look like. I imagine at the point where we scrap the old one and switch, we'll move all the files out of angular directories to one level up. My next task is to get the index page actually working correctly. The work involved is really understanding what all the necessary parts are on the existing page, and porting it over to the new framework.
          Hide
          Erick Erickson added a comment -

          There is a ton of stuff we need to do to make this "modern" and "cloud friendly". I created SOLR-6082 as an umbrella some time ago, there are some JIRAs linked to that one as well, so I figure to link it in here.

          This really is an epic task, I should think that using the experimental_ui end point (or whatever) would be a great place to start and would allow multiple people to contribute. Personally I have no objection to checking in just the framework that doesn't actually do anything then iterate. Others may beg to differ of course.

          One thing that's been on my mind; the current Admin UI has its roots in the single-server days, with SolrCloud added on. Is there a clean way to make SolrCloud support a first-class citizen? For instance, what would be really cool is to be able to see all your servers whether or not they had a collection, ctrl_click on, say, 3 of them and be able to create a collection on those three..... Clicking a configset say... you see where this is going ...

          Show
          Erick Erickson added a comment - There is a ton of stuff we need to do to make this "modern" and "cloud friendly". I created SOLR-6082 as an umbrella some time ago, there are some JIRAs linked to that one as well, so I figure to link it in here. This really is an epic task, I should think that using the experimental_ui end point (or whatever) would be a great place to start and would allow multiple people to contribute. Personally I have no objection to checking in just the framework that doesn't actually do anything then iterate. Others may beg to differ of course. One thing that's been on my mind; the current Admin UI has its roots in the single-server days, with SolrCloud added on. Is there a clean way to make SolrCloud support a first-class citizen? For instance, what would be really cool is to be able to see all your servers whether or not they had a collection, ctrl_click on, say, 3 of them and be able to create a collection on those three..... Clicking a configset say... you see where this is going ...
          Hide
          Upayavira added a comment -

          I've started working on this. I suspect it could be easier than I thought.

          See: https://github.com/upayavira/solr-angular-ui/tree/solr5507 in solr/webapp/web. If you load http://localhost:8983/solr/index.html, you'll see the new UI, which is currently extremely bare-bones, just supporting some basic service calls. Next task is to get the wrapper HTML up and working, then make paging work, then start working through each page one at a time.

          to Erick Erickson: Your comments are good. My aim is to replicate the functionality of the existing UI, at least to get a reasonable distance into that, and then allow us to think about what sort of UI we really want. For example, if you start up a Solr with no cores or collections, you should be prompted with a page offering to create one for you. No idea when 5.0 is due to arrive, but I'm gonna try and run quickly with this in the hope that we can have some funky new UI features to help make 5.0 more special - working alongside the bin/solr stuff.

          Show
          Upayavira added a comment - I've started working on this. I suspect it could be easier than I thought. See: https://github.com/upayavira/solr-angular-ui/tree/solr5507 in solr/webapp/web. If you load http://localhost:8983/solr/index.html , you'll see the new UI, which is currently extremely bare-bones, just supporting some basic service calls. Next task is to get the wrapper HTML up and working, then make paging work, then start working through each page one at a time. to Erick Erickson : Your comments are good. My aim is to replicate the functionality of the existing UI, at least to get a reasonable distance into that, and then allow us to think about what sort of UI we really want. For example, if you start up a Solr with no cores or collections, you should be prompted with a page offering to create one for you. No idea when 5.0 is due to arrive, but I'm gonna try and run quickly with this in the hope that we can have some funky new UI features to help make 5.0 more special - working alongside the bin/solr stuff.
          Hide
          Erick Erickson added a comment -

          Upayavira Grabbed the code from your fork and compiled. The index.html URL gives me just a json response. Which is fine if that's what you expect, I know it's still very early going. I'm wondering though whether I'm missing a library or something, in which case I'll just be patient

          Here's a thought though. IMO, the biggest shortcoming of the current UI is that it's not SolrCloud-friendly. What do you think about prioritizing spiffy new SolrCloud-friendly stuff before replicating the current functionality? True, people would be flipping back and forth between the two for a while, but spiffy new cloud stuff would add functionality...

          It's up to the people doing the work of course, this is just a comment from the "peanut gallery", people doing the work get to decide ...

          Either way, the infrastructure needs to be in place first I'd guess. Thanks for taking this on!

          Wheeeee! Here we go!

          Show
          Erick Erickson added a comment - Upayavira Grabbed the code from your fork and compiled. The index.html URL gives me just a json response. Which is fine if that's what you expect, I know it's still very early going. I'm wondering though whether I'm missing a library or something, in which case I'll just be patient Here's a thought though. IMO, the biggest shortcoming of the current UI is that it's not SolrCloud-friendly. What do you think about prioritizing spiffy new SolrCloud-friendly stuff before replicating the current functionality? True, people would be flipping back and forth between the two for a while, but spiffy new cloud stuff would add functionality... It's up to the people doing the work of course, this is just a comment from the "peanut gallery", people doing the work get to decide ... Either way, the infrastructure needs to be in place first I'd guess. Thanks for taking this on! Wheeeee! Here we go!
          Hide
          Jack Krupansky added a comment -

          This issue has gotten confused. Please clarify the summary and description to inform readers whether the intention is:

          1. Simply "refactor" the implementation to make the code more maintainable and extensible.
          2. Add features to the existing UI to cater to advanced users.
          3. Revamp the UI itself to cater to new and novice users.
          4. Replace the existing UI or supplement it with two UI's, one for novices (guides them through processes) and one for experts (access more features more easily.)

          IOW, what are the "requirements" here?

          I'm not opposed to any of the above, but the original issue summary and description seemed more focused on the internal implementation rather than the externals of a new UI.

          Show
          Jack Krupansky added a comment - This issue has gotten confused. Please clarify the summary and description to inform readers whether the intention is: 1. Simply "refactor" the implementation to make the code more maintainable and extensible. 2. Add features to the existing UI to cater to advanced users. 3. Revamp the UI itself to cater to new and novice users. 4. Replace the existing UI or supplement it with two UI's, one for novices (guides them through processes) and one for experts (access more features more easily.) IOW, what are the "requirements" here? I'm not opposed to any of the above, but the original issue summary and description seemed more focused on the internal implementation rather than the externals of a new UI.
          Hide
          Upayavira added a comment -

          The way I see it, this ticket is about changing the underlying infrastructure to be one that is more amenable to extension.

          Any other features/extensions that this should make possible will occur within their own tickets.

          Whether we go for a complete rewrite, then add new features, or do a partial rewrite, or what, who knows, but as you are suggesting, Jack Krupansky, this ticket is merely relating to the feature-for-feature rewrite. All I ask, though, is that you forgive the occasional burst of ebullient enthusiasm!

          Show
          Upayavira added a comment - The way I see it, this ticket is about changing the underlying infrastructure to be one that is more amenable to extension. Any other features/extensions that this should make possible will occur within their own tickets. Whether we go for a complete rewrite, then add new features, or do a partial rewrite, or what, who knows, but as you are suggesting, Jack Krupansky , this ticket is merely relating to the feature-for-feature rewrite. All I ask, though, is that you forgive the occasional burst of ebullient enthusiasm!
          Hide
          Upayavira added a comment -

          The code on github ( https://github.com/upayavira/solr-angular-ui/tree/solr5507 in solr/webapp/web ) just got waaaay better. The paging is there (in principle) and the first page - the index page, with the graphs on the right, is implemented. This should be a feature for feature match.

          I shall just work down, one page at a time now.

          Show
          Upayavira added a comment - The code on github ( https://github.com/upayavira/solr-angular-ui/tree/solr5507 in solr/webapp/web ) just got waaaay better. The paging is there (in principle) and the first page - the index page, with the graphs on the right, is implemented. This should be a feature for feature match. I shall just work down, one page at a time now.
          Hide
          Alexandre Rafalovitch added a comment -

          Do you know how you are planning to address the admin-extra pages? They are useful but had issues with global style resets, so were not used much.

          Show
          Alexandre Rafalovitch added a comment - Do you know how you are planning to address the admin-extra pages? They are useful but had issues with global style resets, so were not used much.
          Hide
          Upayavira added a comment -

          Personally, I hope they will go away quietly. Beyond that, I haven't thought about it yet. This will be much more extensible, so perhaps we just allow people to add new pages as and when.

          What have people used them for, and what are 'global style resets'?

          Show
          Upayavira added a comment - Personally, I hope they will go away quietly. Beyond that, I haven't thought about it yet. This will be much more extensible, so perhaps we just allow people to add new pages as and when. What have people used them for, and what are 'global style resets'?
          Hide
          Alexandre Rafalovitch added a comment -

          Well, the benefits were that they were a file with the collection config, so that was - theoretically - an easy way to do a collection-specific add-on, including extra pages in the menu tree. I am not sure if having Admin UI in AngularJS will by itself solve the same use case. Unless you building-in some fancy magic router.

          As to the global style resets, the default CSS was AFAIK resetting all the styles (headers, etc). So, if you just wanted a quick admin-extra page, your font was set to 12 points and so were all your headers. So, it was fairly painful. The solution would have been to have the CSS styles reset scoped so it did not affect the included extra pages. But nobody ever worked on it. I am not sure if there was even a JIRA.

          Show
          Alexandre Rafalovitch added a comment - Well, the benefits were that they were a file with the collection config, so that was - theoretically - an easy way to do a collection-specific add-on, including extra pages in the menu tree. I am not sure if having Admin UI in AngularJS will by itself solve the same use case. Unless you building-in some fancy magic router. As to the global style resets, the default CSS was AFAIK resetting all the styles (headers, etc). So, if you just wanted a quick admin-extra page, your font was set to 12 points and so were all your headers. So, it was fairly painful. The solution would have been to have the CSS styles reset scoped so it did not affect the included extra pages. But nobody ever worked on it. I am not sure if there was even a JIRA.
          Hide
          Upayavira added a comment -

          Erick Erickson please feel free to make a dependent issue for your SolrCloud enhancement, it is a good idea that shouldn't be lost.

          Show
          Upayavira added a comment - Erick Erickson please feel free to make a dependent issue for your SolrCloud enhancement, it is a good idea that shouldn't be lost.
          Hide
          Jack Krupansky added a comment -

          All I ask, though, is that you forgive the occasional burst of ebullient enthusiasm!

          No need for it to be forgiven... all ebullient enthusiasm is always welcome and encouraged.

          Show
          Jack Krupansky added a comment - All I ask, though, is that you forgive the occasional burst of ebullient enthusiasm! No need for it to be forgiven... all ebullient enthusiasm is always welcome and encouraged.
          Hide
          Erick Erickson added a comment -

          My desire here is for the really annoying error messages to go away if the files are misplaced...

          I have no real feel for whether they are useful enough to try to keep around anyway, up to the people doing the work of course.

          Show
          Erick Erickson added a comment - My desire here is for the really annoying error messages to go away if the files are misplaced... I have no real feel for whether they are useful enough to try to keep around anyway, up to the people doing the work of course.
          Hide
          Erick Erickson added a comment -

          Upayavira Added a comment to SOLR-6082 about prioritization, I think that's enough.

          Show
          Erick Erickson added a comment - Upayavira Added a comment to SOLR-6082 about prioritization, I think that's enough.
          Hide
          Upayavira added a comment -

          index and logging pages complete on the github branch. The only difference I can see is the fact that column widths are different on the logging page. Otherwise, it should be a feature-for-feature match.

          Show
          Upayavira added a comment - index and logging pages complete on the github branch. The only difference I can see is the fact that column widths are different on the logging page. Otherwise, it should be a feature-for-feature match.
          Hide
          Upayavira added a comment -

          "Connection lost" functionality implemented. It intercepts errors on all HTTP requests, and shows a "connection lost" dialog. It continues to retry, until, when it succeeds, shows a "connection recovered" message and then proceeds where it left off.

          "loading" functionality is there in the backend, and shows ugly on the front end. I'd appreciate ideas as to how to show that we are "loading" some data. I've got a spinning circle (see the logging page), but am not yet sure where to put it!

          "http errors" - non-timeouts should give an error message at the top of the page with a red 'exception' heading.

          Unlike pretty much everything else I've done, this is new code, not a simple refactoring of the existing, so I would appreciate some folks trying it out. Kill Solr - restart it, make Solr return http errors, see if they display well.

          Show
          Upayavira added a comment - "Connection lost" functionality implemented. It intercepts errors on all HTTP requests, and shows a "connection lost" dialog. It continues to retry, until, when it succeeds, shows a "connection recovered" message and then proceeds where it left off. "loading" functionality is there in the backend, and shows ugly on the front end. I'd appreciate ideas as to how to show that we are "loading" some data. I've got a spinning circle (see the logging page), but am not yet sure where to put it! "http errors" - non-timeouts should give an error message at the top of the page with a red 'exception' heading. Unlike pretty much everything else I've done, this is new code, not a simple refactoring of the existing, so I would appreciate some folks trying it out. Kill Solr - restart it, make Solr return http errors, see if they display well.
          Hide
          Upayavira added a comment -

          Attached a patch, against branch_5x when this project started (a few weeks ago). Created in git, I believe will apply to SVN checkout with:

          cd $workspace/solr/webapp/web
          patch -p0 < SOLR5507.patch

          Show
          Upayavira added a comment - Attached a patch, against branch_5x when this project started (a few weeks ago). Created in git, I believe will apply to SVN checkout with: cd $workspace/solr/webapp/web patch -p0 < SOLR5507.patch
          Hide
          Upayavira added a comment -

          Status:

          • Main page: complete excepting searchable cores dropdown
          • Dashboard: complete
          • Logging: complete
          • Logging levels: requires jstree impl or replacement
          • Core admin: partially done
          • Java properties: not done
          • Thread Dump: complate
          • Overview: partial
          • Analysis: not done
          • Data import: not done
          • Documents: not done
          • Files: not done
          • Ping: not done
          • Plugins/stats: not done
          • Query: not done
          • Replication: not done
          • Schema Browser: not done
          Show
          Upayavira added a comment - Status: Main page: complete excepting searchable cores dropdown Dashboard: complete Logging: complete Logging levels: requires jstree impl or replacement Core admin: partially done Java properties: not done Thread Dump: complate Overview: partial Analysis: not done Data import: not done Documents: not done Files: not done Ping: not done Plugins/stats: not done Query: not done Replication: not done Schema Browser: not done
          Hide
          Upayavira added a comment -

          Query tab is done.

          Anyone willing to commit this, so that more folks can play/find bugs?

          Show
          Upayavira added a comment - Query tab is done. Anyone willing to commit this, so that more folks can play/find bugs?
          Hide
          Erick Erickson added a comment -

          And here I was just wondering what I'd do today after I finish up a document....

          Let me give it a quick spin. Some questions:

          > I'm assuming that this doesn't affect the current admin UI so it's optional in that sense, right?
          > The patch from the 2nd is the current one?
          > Let's assume that by the time 5.1 rolls around we don't want to show this for some reason, say we want to polish more. Can we make this change invisible by just removing index.html or other simple step that leaves the bulk of the code there but just doesn't allow people to find it?

          Shalin just set the 5.0 RC label, which means the timing is fortuitous as we can put it on both trunk and 5.1 and have time for it to bake.

          So, assuming there are no objections I'll commit this Real Soon Now (maybe today, but I'm always over-optimistic) and open an umbrella JIRA for additional work. I'm guessing that you can think of about a dozen sub-JIRAs off the top of your head, maybe we can get some additional fingers on keyboards once the structure is in place..

          Show
          Erick Erickson added a comment - And here I was just wondering what I'd do today after I finish up a document.... Let me give it a quick spin. Some questions: > I'm assuming that this doesn't affect the current admin UI so it's optional in that sense, right? > The patch from the 2nd is the current one? > Let's assume that by the time 5.1 rolls around we don't want to show this for some reason, say we want to polish more. Can we make this change invisible by just removing index.html or other simple step that leaves the bulk of the code there but just doesn't allow people to find it? Shalin just set the 5.0 RC label, which means the timing is fortuitous as we can put it on both trunk and 5.1 and have time for it to bake. So, assuming there are no objections I'll commit this Real Soon Now (maybe today, but I'm always over-optimistic) and open an umbrella JIRA for additional work. I'm guessing that you can think of about a dozen sub-JIRAs off the top of your head, maybe we can get some additional fingers on keyboards once the structure is in place..
          Hide
          Upayavira added a comment -

          Erick,

          I have been careful to keep it alongside the current admin UI, which is unaffected.

          Visit http://localhost:8983/solr/index.html to see the new one.

          The only change that would be done to make this the real one is to make it render index.html, not admin.html at the root /solr/ URL.

          I can upload a new patch. I have been working off my github fork, which contains the latest.

          Removing index.html will make this invisible, as you suggest.

          As to sub-tasks, what I'm finding is that there are some JS libraries used, such as jstree, or chosen, which I haven't yet made play nicely with Angular, although I'm getting better at it. Those are clear tasks that could be undertaken by others.

          My plan is to keep giving this a few hours a day until the whole thing is done.

          Thanks for jumping on this!

          Show
          Upayavira added a comment - Erick, I have been careful to keep it alongside the current admin UI, which is unaffected. Visit http://localhost:8983/solr/index.html to see the new one. The only change that would be done to make this the real one is to make it render index.html, not admin.html at the root /solr/ URL. I can upload a new patch. I have been working off my github fork, which contains the latest. Removing index.html will make this invisible, as you suggest. As to sub-tasks, what I'm finding is that there are some JS libraries used, such as jstree, or chosen, which I haven't yet made play nicely with Angular, although I'm getting better at it. Those are clear tasks that could be undertaken by others. My plan is to keep giving this a few hours a day until the whole thing is done. Thanks for jumping on this!
          Hide
          Upayavira added a comment -

          Erick,

          I have been careful to keep it alongside the current admin UI, which is unaffected.

          Visit http://localhost:8983/solr/index.html to see the new one.

          The only change that would be done to make this the real one is to make it render index.html, not admin.html at the root /solr/ URL.

          I can upload a new patch. I have been working off my github fork, which contains the latest.

          Removing index.html will make this invisible, as you suggest.

          As to sub-tasks, what I'm finding is that there are some JS libraries used, such as jstree, or chosen, which I haven't yet made play nicely with Angular, although I'm getting better at it. Those are clear tasks that could be undertaken by others.

          My plan is to keep giving this a few hours a day until the whole thing is done.

          Thanks for jumping on this!

          Show
          Upayavira added a comment - Erick, I have been careful to keep it alongside the current admin UI, which is unaffected. Visit http://localhost:8983/solr/index.html to see the new one. The only change that would be done to make this the real one is to make it render index.html, not admin.html at the root /solr/ URL. I can upload a new patch. I have been working off my github fork, which contains the latest. Removing index.html will make this invisible, as you suggest. As to sub-tasks, what I'm finding is that there are some JS libraries used, such as jstree, or chosen, which I haven't yet made play nicely with Angular, although I'm getting better at it. Those are clear tasks that could be undertaken by others. My plan is to keep giving this a few hours a day until the whole thing is done. Thanks for jumping on this!
          Hide
          Erick Erickson added a comment -

          yeah, an updated patch would be helpful, keeps track of what we commit
          with the JIRA for one thing, and makes my life easier for another

          Show
          Erick Erickson added a comment - yeah, an updated patch would be helpful, keeps track of what we commit with the JIRA for one thing, and makes my life easier for another
          Hide
          Upayavira added a comment -

          attached patch containing latest state of play, with query pane working

          Show
          Upayavira added a comment - attached patch containing latest state of play, with query pane working
          Hide
          Upayavira added a comment -

          Discovered there was a gitignore further up preventing my lib directory from getting into git, which also broke the patch. I've uploaded a new patch that has the JS dependencies included.

          Show
          Upayavira added a comment - Discovered there was a gitignore further up preventing my lib directory from getting into git, which also broke the patch. I've uploaded a new patch that has the JS dependencies included.
          Hide
          Erick Erickson added a comment -

          Two questions:

          1> there is a top-level README.txt that is new to your fork included in the patch. I've removed it from my copy. Is that OK?
          2> at the top level, the .gitignore file has two new entries, /solr/example and /solr/server. I'm guessing this file should not be changed at this point.

          I'll put up a patch with the two above changes if they're appropriate before I commit the code.

          When I build and go to the admin page, I see two errors about "SolrCore initialization errors, please check your logs" but no errors in the relevant log file. I started with 'bin/solr start -e techproducts'

          None of the links on the page do anything.

          The old admin UI does, however, show a valid techproducts core with what I'd expect.

          I suspect I'm missing some dependencies. I applied the 1.43M patch above (just double checked).

          So let's assume it is a dependency problem, where would I look? And would it be helpful to chat tomorrow? I have to leave here by 9:30 PST for the rest of the day, and there's a chance I'll be on a con call but we can try.

          If that won't work, how about Friday?

          Show
          Erick Erickson added a comment - Two questions: 1> there is a top-level README.txt that is new to your fork included in the patch. I've removed it from my copy. Is that OK? 2> at the top level, the .gitignore file has two new entries, /solr/example and /solr/server. I'm guessing this file should not be changed at this point. I'll put up a patch with the two above changes if they're appropriate before I commit the code. When I build and go to the admin page, I see two errors about "SolrCore initialization errors, please check your logs" but no errors in the relevant log file. I started with 'bin/solr start -e techproducts' None of the links on the page do anything. The old admin UI does , however, show a valid techproducts core with what I'd expect. I suspect I'm missing some dependencies. I applied the 1.43M patch above (just double checked). So let's assume it is a dependency problem, where would I look? And would it be helpful to chat tomorrow? I have to leave here by 9:30 PST for the rest of the day, and there's a chance I'll be on a con call but we can try. If that won't work, how about Friday?
          Hide
          Upayavira added a comment -

          Ping me. I've been developing against git, and haven't yet tried to import directly into an SVN checkout. I'll give it a go and see what works/breaks.

          Show
          Upayavira added a comment - Ping me. I've been developing against git, and haven't yet tried to import directly into an SVN checkout. I'll give it a go and see what works/breaks.
          Hide
          Upayavira added a comment -

          Fixing a small typo that was breaking the app on other people's browsers

          Show
          Upayavira added a comment - Fixing a small typo that was breaking the app on other people's browsers
          Hide
          Erick Erickson added a comment -

          Removed bogus README.txt file and what I think are inadvertent entries in .gitignore.

          Show
          Erick Erickson added a comment - Removed bogus README.txt file and what I think are inadvertent entries in .gitignore.
          Hide
          Erick Erickson added a comment -

          OK, this compiles and shows new stuff. As Upayavira mentions, it's not complete by any means, but the structure is in place.

          So my question is where to go from here. Upayavira has a Git repo he's working with.
          There are at least three ways to take this forward:

          1> Work with Upayavira's Git repo, he'd have to volunteer to keep it current and all that.
          2> Create an SVN branch for ongoing work.
          3> Just check this in, close this JIRA and work with sub JIRAs and maybe an umbrella JIRA.

          I kind of like this last as that would keep things from getting too far out of date. Case in point:
          > The attached patch fails precommit because all the new files don't have the
          proper svn:eol-style bits set, which is easy to fix.
          > Even with the eol-style problem fixed, it fails precommit with
          /lucene/common-build.xml:1830: Rat problems were found! no idea what
          this is trying to tell me, what the heck is rat?

          This is not my day to have precommit play nice.

          Show
          Erick Erickson added a comment - OK, this compiles and shows new stuff. As Upayavira mentions, it's not complete by any means, but the structure is in place. So my question is where to go from here. Upayavira has a Git repo he's working with. There are at least three ways to take this forward: 1> Work with Upayavira's Git repo, he'd have to volunteer to keep it current and all that. 2> Create an SVN branch for ongoing work. 3> Just check this in, close this JIRA and work with sub JIRAs and maybe an umbrella JIRA. I kind of like this last as that would keep things from getting too far out of date. Case in point: > The attached patch fails precommit because all the new files don't have the proper svn:eol-style bits set, which is easy to fix. > Even with the eol-style problem fixed, it fails precommit with /lucene/common-build.xml:1830: Rat problems were found! no idea what this is trying to tell me, what the heck is rat? This is not my day to have precommit play nice.
          Hide
          Upayavira added a comment -

          Regarding README and gitignore, README is intended for a github audience, and gitignore helps me out during dev. They will be excluded from future patches.

          Rat is telling you that we have files in the tree without correct license headers. I found one (index.js) which I have fixed in my git repo.

          There's also a heap of stuff there that needs attributing correctly - 90% is stuff that is in the current admin UI but that we didn't identify as dependencies that we should have been listing somewhere. Sorting this out is on my todo list, I'll make sure that before we merge this anywhere, licensing is handled correctly.

          Show
          Upayavira added a comment - Regarding README and gitignore, README is intended for a github audience, and gitignore helps me out during dev. They will be excluded from future patches. Rat is telling you that we have files in the tree without correct license headers. I found one (index.js) which I have fixed in my git repo. There's also a heap of stuff there that needs attributing correctly - 90% is stuff that is in the current admin UI but that we didn't identify as dependencies that we should have been listing somewhere. Sorting this out is on my todo list, I'll make sure that before we merge this anywhere, licensing is handled correctly.
          Hide
          Upayavira added a comment - - edited

          Status:
          Main page: complete
          Dashboard: complete
          Logging: complete
          Logging levels: complete
          Cloud/tree: not done
          Cloud/graph: not done
          Cloud/radial graph: not done
          Cloud/dump: not done
          Core admin: complete
          Java properties: complete
          Thread Dump: complete
          Overview: partial
          Analysis: complete
          Data import: not done
          Documents: not done
          Files: not done
          Ping: not done
          Plugins/stats: not done
          Query: complete (excepting storing params in URL)
          Replication: not done
          Schema Browser: not done

          Completed: 9/21

          Show
          Upayavira added a comment - - edited Status: Main page: complete Dashboard: complete Logging: complete Logging levels: complete Cloud/tree: not done Cloud/graph: not done Cloud/radial graph: not done Cloud/dump: not done Core admin: complete Java properties: complete Thread Dump: complete Overview: partial Analysis: complete Data import: not done Documents: not done Files: not done Ping: not done Plugins/stats: not done Query: complete (excepting storing params in URL) Replication: not done Schema Browser: not done Completed: 9/21
          Hide
          Upayavira added a comment -

          Erick,

          Firstly, I think we should just commit this to trunk. It sits alongside the current admin UI without interrupting it, so no issues.

          Secondly, let me know how you do the pre-commit steps - am I in a position to do it also? If so, I'll see if I can resolve the RAT issues.

          Show
          Upayavira added a comment - Erick, Firstly, I think we should just commit this to trunk. It sits alongside the current admin UI without interrupting it, so no issues. Secondly, let me know how you do the pre-commit steps - am I in a position to do it also? If so, I'll see if I can resolve the RAT issues.
          Hide
          Erick Erickson added a comment -

          Upayavira:

          Yep, this is on my list, but it's been a busy week. May be this weekend before I can go there.

          If we commit it to trunk, I should think we might as well commit it to 5x too, assuming we can easily disable it before a 5.1 comes out if we need to.

          precommit is just a target for ant, so just doing an "ant precommit" from the root will run it.

          Show
          Erick Erickson added a comment - Upayavira: Yep, this is on my list, but it's been a busy week. May be this weekend before I can go there. If we commit it to trunk, I should think we might as well commit it to 5x too, assuming we can easily disable it before a 5.1 comes out if we need to. precommit is just a target for ant, so just doing an "ant precommit" from the root will run it.
          Hide
          Erick Erickson added a comment -

          Patch just cleans up the svn-eolstyle warnings. FYI, the command to do that is:
          svn propset svn:eol-style native file_path
          a body has to get through that to get to the rat errors. Below are the files reported with "Unknown Licenses:"

          Upayavira:
          In case you're wondering why I'm not checking these in, the Jenkins builds will fail if the precommit step fails. I notice these are MIT licenses, perhaps we can just add that license to the list of known good ones? I confess I have no clue how though...

          /Users/Erick/apache/trunk_5507/solr/webapp/web/css/angular/chosen.css
          [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/js/angular/controllers/index.js
          [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/angular-cookies.js
          [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/angular-cookies.min.js
          [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/angular-resource.min.js
          [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/angular-route.js
          [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/angular-route.min.js
          [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/angular-sanitize.js
          [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/angular-sanitize.min.js
          [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/angular.js
          [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/angular.min.js
          [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/chosen.jquery.js
          [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/chosen.jquery.min.js
          [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/chosen.js
          [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/jquery-2.1.3.min.js
          [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/ngtimeago.js

          Show
          Erick Erickson added a comment - Patch just cleans up the svn-eolstyle warnings. FYI, the command to do that is: svn propset svn:eol-style native file_path a body has to get through that to get to the rat errors. Below are the files reported with "Unknown Licenses:" Upayavira: In case you're wondering why I'm not checking these in, the Jenkins builds will fail if the precommit step fails. I notice these are MIT licenses, perhaps we can just add that license to the list of known good ones? I confess I have no clue how though... /Users/Erick/apache/trunk_5507/solr/webapp/web/css/angular/chosen.css [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/js/angular/controllers/index.js [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/angular-cookies.js [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/angular-cookies.min.js [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/angular-resource.min.js [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/angular-route.js [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/angular-route.min.js [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/angular-sanitize.js [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/angular-sanitize.min.js [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/angular.js [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/angular.min.js [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/chosen.jquery.js [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/chosen.jquery.min.js [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/chosen.js [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/jquery-2.1.3.min.js [rat] /Users/Erick/apache/trunk_5507/solr/webapp/web/lib/ngtimeago.js
          Hide
          Upayavira added a comment -

          I've managed to get RAT to be happy locally.

          To run rat on the webapp alone, enter solr/webapp and run 'ant rat-sources'.

          My source files are currently mid-development, so I will submit a new Rat-friendly patch when get to my next milestone.

          Note, rather than adding headers to all of the AngularJS files, I'm proposing to add this patch to lucene/common-build.xml, under the RAT, MIT license section:

          <!-- AngularJS -->
          <pattern substring=" License: MIT"/>

          Show
          Upayavira added a comment - I've managed to get RAT to be happy locally. To run rat on the webapp alone, enter solr/webapp and run 'ant rat-sources'. My source files are currently mid-development, so I will submit a new Rat-friendly patch when get to my next milestone. Note, rather than adding headers to all of the AngularJS files, I'm proposing to add this patch to lucene/common-build.xml, under the RAT, MIT license section: <!-- AngularJS --> <pattern substring=" License: MIT"/>
          Hide
          Upayavira added a comment -

          Patch that keeps RAT happy - I have executed (cd solr/webapp; ant rat-sources) without complaint.

          To achieve this I added license headers to all of the library files. I also opted to add licenses to each AngularJS library file, rather than modify lucene/common-build.

          This patch also includes a functionally correct cloud/tree page.

          Show
          Upayavira added a comment - Patch that keeps RAT happy - I have executed (cd solr/webapp; ant rat-sources) without complaint. To achieve this I added license headers to all of the library files. I also opted to add licenses to each AngularJS library file, rather than modify lucene/common-build. This patch also includes a functionally correct cloud/tree page.
          Hide
          Erick Erickson added a comment -

          Passes precommit, I took a quick look at it and the bits you've done already seem to be in place, but can't do any more looking until tomorrow.

          So, let's say this passes the unit tests. I think it would be best to create a bunch of sub-JIRAs for further improvements rather than continue to revise this patch. I suppose we could also create additional patches that are the delta for other work (with different labels), it's just that what I don't want to to is keep re-applying the changes contained in this patch as that's a sticky wicket....

          Show
          Erick Erickson added a comment - Passes precommit, I took a quick look at it and the bits you've done already seem to be in place, but can't do any more looking until tomorrow. So, let's say this passes the unit tests. I think it would be best to create a bunch of sub-JIRAs for further improvements rather than continue to revise this patch. I suppose we could also create additional patches that are the delta for other work (with different labels), it's just that what I don't want to to is keep re-applying the changes contained in this patch as that's a sticky wicket....
          Hide
          Upayavira added a comment -

          Great that precommit works!

          I am generating these patches with a diff between a base git hash and my latest commit. Once you commit a patch, I will move the hash I use as a base. I'll need to do that regardless of whether we continue with this one ticket, or split into multiples. Thus, patches that I submit will always be deltas against the current state of SVN - I'll keep that easy for you.

          Show
          Upayavira added a comment - Great that precommit works! I am generating these patches with a diff between a base git hash and my latest commit. Once you commit a patch, I will move the hash I use as a base. I'll need to do that regardless of whether we continue with this one ticket, or split into multiples. Thus, patches that I submit will always be deltas against the current state of SVN - I'll keep that easy for you.
          Hide
          Upayavira added a comment - - edited

          Cloud tab is almost there. Just need to complete the 'debug/dump' and clipboard copying. (uploaded new patch)

          Show
          Upayavira added a comment - - edited Cloud tab is almost there. Just need to complete the 'debug/dump' and clipboard copying. (uploaded new patch)
          Hide
          Erick Erickson added a comment -

          Upayavira:

          OK, back after traveling and caught up. I'm running this through precommit and test now. Should I check it in afterwards or do you have something else you want to do first?

          Show
          Erick Erickson added a comment - Upayavira: OK, back after traveling and caught up. I'm running this through precommit and test now. Should I check it in afterwards or do you have something else you want to do first?
          Hide
          Erick Erickson added a comment -

          Upayavira Should I commit this or do you have something else to add for the first cut?

          Show
          Erick Erickson added a comment - Upayavira Should I commit this or do you have something else to add for the first cut?
          Hide
          Upayavira added a comment -

          I have nothing more yet, hopefully more next week, so commit away.

          Show
          Upayavira added a comment - I have nothing more yet, hopefully more next week, so commit away.
          Hide
          Erick Erickson added a comment -

          Patch with CHANGES.txt entry. I'm going to close this after the 5x gets checked in later tonight, let's open more JIRAs and relate them to this one.

          Show
          Erick Erickson added a comment - Patch with CHANGES.txt entry. I'm going to close this after the 5x gets checked in later tonight, let's open more JIRAs and relate them to this one.
          Hide
          ASF subversion and git services added a comment -

          Commit 1661606 from Erick Erickson in branch 'dev/trunk'
          [ https://svn.apache.org/r1661606 ]

          SOLR-5507: Admin UI - Refactoring using AngularJS

          Show
          ASF subversion and git services added a comment - Commit 1661606 from Erick Erickson in branch 'dev/trunk' [ https://svn.apache.org/r1661606 ] SOLR-5507 : Admin UI - Refactoring using AngularJS
          Hide
          Erick Erickson added a comment -

          Thanks Upayavira! Let's open up associated JIRAs, the patches for this one will get harder to untangle if we add more I think.

          Show
          Erick Erickson added a comment - Thanks Upayavira! Let's open up associated JIRAs, the patches for this one will get harder to untangle if we add more I think.
          Hide
          ASF subversion and git services added a comment -

          Commit 1661607 from Erick Erickson in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1661607 ]

          SOLR-5507: Admin UI - Refactoring using AngularJS

          Show
          ASF subversion and git services added a comment - Commit 1661607 from Erick Erickson in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1661607 ] SOLR-5507 : Admin UI - Refactoring using AngularJS
          Hide
          Timothy Potter added a comment -

          Bulk close after 5.1 release

          Show
          Timothy Potter added a comment - Bulk close after 5.1 release

            People

            • Assignee:
              Erick Erickson
              Reporter:
              Stefan Matheis (steffkes)
            • Votes:
              7 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development