Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: web gui
    • Labels:
      None

      Description

      Provide an example user interface for Solr (web application) for people to try out Solr's capabilities.

      1. SOLR-634.patch
        171 kB
        Lars Kotthoff
      2. solr-ui.tar.gz
        6.73 MB
        Lars Kotthoff

        Issue Links

          Activity

          Hide
          Erick Erickson added a comment -

          Velocity & etc do this I think.

          Show
          Erick Erickson added a comment - Velocity & etc do this I think.
          Hide
          Lance Norskog added a comment -

          Please close this.

          Show
          Lance Norskog added a comment - Please close this.
          Hide
          Lars Kotthoff added a comment -

          I basically chose not to use SolrJ because the UI was meant to be separate and not depend on Solr – this is only part of a bigger project (not all of it was open sourced). I think there might have been a specific issue (something that didn't work properly or wasn't supported at that time in SolrJ), but I can't remember now.

          I don't have a version of SolrAdapter which uses SolrJ, but I think that it would be quite straightforward to implement it.

          Show
          Lars Kotthoff added a comment - I basically chose not to use SolrJ because the UI was meant to be separate and not depend on Solr – this is only part of a bigger project (not all of it was open sourced). I think there might have been a specific issue (something that didn't work properly or wasn't supported at that time in SolrJ), but I can't remember now. I don't have a version of SolrAdapter which uses SolrJ, but I think that it would be quite straightforward to implement it.
          Hide
          Otis Gospodnetic added a comment -

          Lars, how come you opted to use HTTPClient directly instead of using SolrJ? (I see no mention of solrj in the manual either). Or perhaps you have a SolrAdapter version that uses SolrJ by now? Thanks.

          Show
          Otis Gospodnetic added a comment - Lars, how come you opted to use HTTPClient directly instead of using SolrJ? (I see no mention of solrj in the manual either). Or perhaps you have a SolrAdapter version that uses SolrJ by now? Thanks.
          Hide
          Lars Kotthoff added a comment -

          Attaching a new tarball with the monolithic spring jar replaced with the module jars required for the application.

          Show
          Lars Kotthoff added a comment - Attaching a new tarball with the monolithic spring jar replaced with the module jars required for the application.
          Hide
          Lars Kotthoff added a comment -

          Regarding testing, we can't use AbstractSolrTestCase for that since it communicates with Solr directly instead over HTTP, thus the servlet code wouldn't be executed. Doing something like JettyWebappTest seems more feasible, although that depends on assembling all the Solr parts required to run it as a webapp to test against. Currently the easiest way to do that is to build the distribution war file. I'm not that familiar with the current build/testing process though, so do correct me if I'm wrong!

          I agree that it'd be better not to have to create and copy the war file for integration testing, but changing the current way will likely require some bigger changes. Let's tackle that as a different issue after this one if the need arises.

          Show
          Lars Kotthoff added a comment - Regarding testing, we can't use AbstractSolrTestCase for that since it communicates with Solr directly instead over HTTP, thus the servlet code wouldn't be executed. Doing something like JettyWebappTest seems more feasible, although that depends on assembling all the Solr parts required to run it as a webapp to test against. Currently the easiest way to do that is to build the distribution war file. I'm not that familiar with the current build/testing process though, so do correct me if I'm wrong! I agree that it'd be better not to have to create and copy the war file for integration testing, but changing the current way will likely require some bigger changes. Let's tackle that as a different issue after this one if the need arises.
          Hide
          Lars Kotthoff added a comment -

          I'm attaching a patch which creates the directory structure and text files in contrib/. The build file was changed to incorporate Solr jars and create a Solr war for the integration tests.

          The binary files (pdf, images, jars) need to be copied manually – the names of the files are included in the patch. Because Solr jar files are incorporated, not all the jars present in the tarball are required.

          Note that the integration tests fail because they depend on SOLR-540. The build will succeed nevertheless though.

          Show
          Lars Kotthoff added a comment - I'm attaching a patch which creates the directory structure and text files in contrib/. The build file was changed to incorporate Solr jars and create a Solr war for the integration tests. The binary files (pdf, images, jars) need to be copied manually – the names of the files are included in the patch. Because Solr jar files are incorporated, not all the jars present in the tarball are required. Note that the integration tests fail because they depend on SOLR-540 . The build will succeed nevertheless though.
          Hide
          Lars Kotthoff added a comment -

          Making this issue depend on SOLR-540 as the current implementation uses wildcard highlighting.

          Show
          Lars Kotthoff added a comment - Making this issue depend on SOLR-540 as the current implementation uses wildcard highlighting.
          Hide
          Lars Kotthoff added a comment -

          I'll look into AbstractSolrTestCase. Currently the integration tests use Solr with an embedded Jetty to verify that we're able to communicate with Solr. I'm inclined to leave it that way, since it's the only way of testing in an environment similar to the target environment.

          The build file already provides targets for building, running the tests, etc. I'll take a closer look at integrating it with the main build script.

          Show
          Lars Kotthoff added a comment - I'll look into AbstractSolrTestCase. Currently the integration tests use Solr with an embedded Jetty to verify that we're able to communicate with Solr. I'm inclined to leave it that way, since it's the only way of testing in an environment similar to the target environment. The build file already provides targets for building, running the tests, etc. I'll take a closer look at integrating it with the main build script.
          Hide
          Shalin Shekhar Mangar added a comment -

          To some extent, yes. I don't think it should be included in the Solr war file though, as it's a separate application.

          That's great. We can start by modifying the existing directory structure in the attached archive to the contrib structure following by DIH.

          Also there's a dependency on the solr.war for the integration tests.

          Can we use the AbstractSolrTestCase or embedded Jetty (see JettyWebappTest) for integration tests instead of relying on solr.war directly? That will simplify the builds.

          For example we need to decide what "package" should do. Compiled files only? Source, too? What about documentation - manual, source of manual, javadoc.

          These targets should do exactly as (or close to) what is done by Solr's build file. We should be able to create and deploy the war file for this contrib deployed alongside Solr in the example/webapps folder so that no manual steps may be needed to see the interface. Let's get the basic compile, package, test working after which we can focus on javadoc, dist, documentation etc.

          Show
          Shalin Shekhar Mangar added a comment - To some extent, yes. I don't think it should be included in the Solr war file though, as it's a separate application. That's great. We can start by modifying the existing directory structure in the attached archive to the contrib structure following by DIH. Also there's a dependency on the solr.war for the integration tests. Can we use the AbstractSolrTestCase or embedded Jetty (see JettyWebappTest) for integration tests instead of relying on solr.war directly? That will simplify the builds. For example we need to decide what "package" should do. Compiled files only? Source, too? What about documentation - manual, source of manual, javadoc. These targets should do exactly as (or close to) what is done by Solr's build file. We should be able to create and deploy the war file for this contrib deployed alongside Solr in the example/webapps folder so that no manual steps may be needed to see the interface. Let's get the basic compile, package, test working after which we can focus on javadoc, dist, documentation etc.
          Hide
          Lars Kotthoff added a comment -

          To some extent, yes. I don't think it should be included in the Solr war file though, as it's a separate application. Also there's a dependency on the solr.war for the integration tests. The included build.xml is really just a skeleton. For example we need to decide what "package" should do. Compiled files only? Source, too? What about documentation – manual, source of manual, javadoc.

          Show
          Lars Kotthoff added a comment - To some extent, yes. I don't think it should be included in the Solr war file though, as it's a separate application. Also there's a dependency on the solr.war for the integration tests. The included build.xml is really just a skeleton. For example we need to decide what "package" should do. Compiled files only? Source, too? What about documentation – manual, source of manual, javadoc.
          Hide
          Shalin Shekhar Mangar added a comment -

          Lars – Can this be modeled after the DataImportHandler (SOLR-469, SOLR-563) contrib builds? The existing solr build file is already capable of building contrib projects though it may still need some modifications to accommodate your contribution.

          Show
          Shalin Shekhar Mangar added a comment - Lars – Can this be modeled after the DataImportHandler ( SOLR-469 , SOLR-563 ) contrib builds? The existing solr build file is already capable of building contrib projects though it may still need some modifications to accommodate your contribution.
          Hide
          Lars Kotthoff added a comment -

          User interface as described and discussed at http://www.nabble.com/Solr-user-interface-td18235277.html. The contents of the tarball is everything in the svn repository.

          Show
          Lars Kotthoff added a comment - User interface as described and discussed at http://www.nabble.com/Solr-user-interface-td18235277.html . The contents of the tarball is everything in the svn repository.

            People

            • Assignee:
              Unassigned
              Reporter:
              Lars Kotthoff
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development