up to all Development Components for VIVO 1.5
Component description
Improve the process of installing and configuring VIVO
- Make the process easier to understand
- Make the commonplace installation easy to accomplish
- Make the unusual installation possible
- Make errors less likely
- Make it easier to detect errors when they occur
- Make it easier to diagnose and fix errors
Scope of the component for v1.5
Smaller tasks – 15 existing JIRA issues:
- Continue developing startup tests and warnings
- Write documentation about Tomcat/Apache configurations for VIVO
- Scan the mailing lists to find commonly occurring problems. Address with better documentation, simpler configuration options, or better error detection.
Larger tasks:
Re-implement the Solr installation
- The most pressing
- By default, Solr should be included within the VIVO webapp, eliminating many of the issues associated with Solr configuration.
- Solr could also be installed in a separate webapp, perhaps on a separate server, for scalability.
Design and document our configuration hierarchy
Divide configuration options into categories:
- Used during the build/deploy process
- Loaded the first time VIVO is run
- Loaded every time VIVO is run
For each of these, what happens when the site upgrades to a newer version of VIVO?
Produce a collection of short “recipe” pages to assist our developers.
What about optional modules? Do they need to be treated differently?
Design and implement an interactive process for configuration
This requires the previous task: “Design and document our configuration hierarchy”
What would it look like?
- The Wordpress installation process is frequently cited as a model
- Require only build/deploy properties to be configured in advance
- All other properties would be configured on first-time startup
- Root user could choose to repeat the configuration process
Design work needed for the component
- There are technical issues to be determined regarding the Solr installation.
- We need to design an overall configuration scheme.
- It would be good if this scheme anticipate the modularity/extension framework.
- Functional design and visual design for the interactive configuration process.
Can this component be addressed in stages?
|
Task |
Depends on |
Time |
|---|---|---|---|
1. |
Existing JIRA issues (not counting those related to Solr installation) |
|
5 days |
2a. |
Change Solr installation so Solr is internal to VIVO |
|
4 days |
2b. |
Enhance Solr installation to allow Solr to be either internal or external |
2a. |
1 day |
3a. |
Design of what our configuration hierarchy should become. |
|
3 days |
3b. |
Document our existing configuration hierarchy. |
|
1 day |
3c. |
Implement the improved configuration hierarchy. |
3a. |
Depends on design |
4a. |
Functional design of interactive configuration process. |
3a. |
2 days |
4b. |
Visual design of interactive configuration process. |
4a. |
2 days |
4c. |
Implementation of interactive configuration process. |
4a., 4b. |
Depends on design |
Dependency on any other component
Essentially none, although the configuration design should take the extension framework into account.
A suggested incremental plan
For release 1.5:
- Address most of the existing JIRA issues
- Re-implement the Solr installation
- Design the configuration hierarchy
- Document the existing configuration conventions as an aid to developers
- Functional design of the interactive configuration process
For later releases:
- Implement the configuration hierarchy
- Visual design of the interactive configuration process
- Implement the interactive configuration process
