...
- Don: agree with vision, but would be good to articulate the reasoning. Could be variations on the theme, e.g. still specify Tomcat directory if desired but copy the whole war file there instead of exploding it first.
- Benjamin: one important use case is being able to download the war file and drop it into Tomcat without building at all.
- Struggle to see how this is going to help me (as a developer)
- Have custom Java files I will have to deploy anyway.
- Ralph: good for adhering to best practices and for testing/evaluation
- Benjamin: Right now, can’t customize branding without modifying the theme directory, which is inside the war. So without other changes, it really will only be useful for evaluation and not production.
- Don: could open up interesting opportunities [related to clustering?]
- Ralph: Docker may be the easiest way to deal with Solr installation and setup
- Do we support latest and greatest Solr or maintain support for multiple versions of Solr as well as ElasticSearch?
- Benjamin: not sure there’s enough of a community to demand or support ElasticSearch at this point
- I18n configuration via runtime.properties without having to edit pom.xmls
- Merged to i18n sprint branch; Benjamin and Brian want a simplification of the mechanism (no requirement for master list of all supported languages) to occur before the feature gets merged to master. Andrew created an issue for this.
- Ralph: has voiced preference in other projects for things to be configurable via GUIs rather than properties files
- Don: some of us prefer the opposite (file-based configuration)
- Discussion of fact that all i18n files are installed at build time and RDF is selectively loaded according to languages enabled in runtime.properties.
- Advantage of more GUI-based configuration would be instant changes without need for restart.
- Benjamin: Maintaining compatibility with third-tier builds may be only a matter of documentation, or small adjustments to pom.xml files.
- JSM JMS messaging approaches
- Don: multiple approaches exist now that rely on eternal processes to build index. My concern with VIVO-scholars is that there is yet another Java process running queries and building index, etc. Much more complex for system administrators than the other configuration issues we talked about earlier.
- Having a common solution for mapping triple changes to document changes and being able to use it in multiple applications would simplify this landscape.
- Ralph: also German use case for audit logging. Seems like first thing this should cover.
- Don interested in creating an MVP that could update FacetView.
- Brian: these discussions seem to be conflating two very diferent use cases
- 1. Low-level listening to RDF changes : can be done by implementing either VIVO’s change listener interface or Jena’s ModelChangedListener (which can be adapted to listen to an RDFService)
- 2. Listening to index changes at a higher level that takes advantage of VIVO’s logic for mapping triple changes to field updates in different index documents. Here it might make sense to start by making a third implementation of the search index interface (after Solr and ElasticSearch) that instead of using the API for a particular index product instead emits generic document update messages that can be consumed by different systems.
...