Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

1) In the sandbox phase, where we are today, users can run Solr as they normally would. If they would like to try the new UI, they need to navigate to the same directory solr/ where webapp/ lives, and they will need to cd into webapp2/  dir. After that, they need to run npm start. That command will build the UI and then allow users to visit both Admin UI's simultaneously. This is a simple effort that will allow the community and the team to provide real-time feedback such that improvements can be made. The application will not be bundled at all in production environments in this phase. Phase one, though not entirely feature complete, is very important for our community to get familiar with the new application and its look and feel. If anyone would like to work through a first commit with me, I will talk with my company and ensure I have the appropriate time to do this work at a reasonable hour (I'm working on this projects 98% of the time, on nights and weekends). I am always available for critical bug fixes or security vulnerabilities because my company depends on Solr quite a bit. The new Admin UI would be available in this phase at 4200 .

2) In phase 2, the app will start with the existing Solr start command. In this case, the admin UI would have production mode enabled, and will be served up in production mode by default. This change will result in a much smaller application, minified, that is compiled AOT, and stored in a dist  folder in the UI application's root. The application will then be packaged by Gradle into a JAR file using the gradle-node-plugin, thereby eliminating the need to have node installed on the system running the application. For implementation details on how this would look, you can view an example here: https://dzone.com/articles/integrating-java-and-npm-builds-using-gradle. You can also count on the documentation that I produce in the README to be very thorough and inclusive of steps, tactics for address errors, and alternative methods of serving the application. The new Admin UI would be available in this phase at 8983  but will be configurable to start at any port that you desire.

Tests

Tests will be executed in a similar fashion and as described in the link above, in the appropriate phases. By the time we reach phase 2, I hope to have worked with committers to get all the Jenkins configurations worked out to support end-to-end testing. There are some things that I need to work out before we are there, but should be done well before we are ready for Solr 9 to be merged. In fact, we should have developed a regular engagement and collaboration for working through the integrating the front end into the global CI pipeline. The added time to the UI tests should be very minimal as the application is much smaller in comparison. I will leave it to the community as to whether we make the UI tests run on every build or only for specific target. My suggestion is that if you expect the UI to work when a backend change is made, it should be added to the standard target. Admittedly, this point warrants further discussion. 

...