Notes

Link on DuraSpace Wiki:

Sacha: UQAM primarily working on documentation. Michel is documenting how to add a new language. There may be additional documentation that could be moved over from the UQAM wiki to the VIVO wiki. Michel and Andrew have been looking at technical documentation; Sacha is focusing on end-user documentation. Sacha has encountered problems in installing VIVO, at least in part due to infrastructure issues (restrictions imposed by those managing the servers). VIVO documentation also assumes server administration background that may be a hurdle.
Andrew: Matthias has written a script to generate sample multilingual data; sounds like he is moving forward with reproducing the ticket he’s working on (optimizing language filtering). Dominik is working on making time for the “firsttime” data reloading issue.

VIVO-1904 and VIVO-1914: would be great if an institution with an existing VIVO installation could test (and document) the upgrade path to 1.12 (with new language functionality).

A&M still needs to upgrade to 1.11 (and potentially TDB; have encountered performance issues with TDB and data ingest).

Relatively significant change to installation of VIVO
This feature would warrant a five-minute video explaining the impact of the change.
Requirement to build VIVO to install it goes away
Downloadable .war file that can be added to Tomcat (or, with minor changes, to Jetty)
Sacha: is there anything that would be lost in moving away from building one’s installation?

Andrew: Customized builds (e.g. three-tier builds) are still possible. Nothing should be lost, but this should make it easier for people who just want to install a standard VIVO.

Andrew: VIVO doesn’t have a pull model for ingest, so the tools still sit outside and push data in. The installation change doesn’t affect that.

Initial configuration data will now be provided in a small context.xml file (VIVO home, default namespace, root user email address).
Pull request needs review

Auto-configuration of Solr: turned out to be more involved for the installer than the copy-the-Solr-configuration-files approach, because (non-cloud) Solr does not support everything we need via the API. A move to SolrCloud would make the automatic configuration more attractive.
Bringing Scholars closer to the VIVO core: something to focus on after i18n work is complete.

William: which has the higher priority? Using existing VIVO infrastructure to populate the Scholars index, or a messaging system? If the latter, the Scholars integration can be built on that.

...