Versions Compared

Old Version 1

changes.mady.by.user Andrew Woods

Saved on

compared with

New Version 2

changes.mady.by.user Brian Lowe

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Paste notes

...

  1. Don Elsborg
  2. Huda Khan 
  3. Benjamin Gross 
  4. Ralph O'Flinn 
  5. Brian Lowe (star)
  6. Michel Héon
  7. Nicolas Dickner
  8. Alexander (Sacha) Jerabek

Agenda

  1. Announcements
    1. ...
  2. The i18n effort continues
    1. Update and goals of vivo-regression-tests
  3. VIVO installation: the vision and requirements
    1. VIVO should be able to be deployed by dropping vivo.war into a servlet container (e.g. Tomcat)
    2. On startup, VIVO should create ${VIVO_HOME}, if it does not exist <-- start here
    3. On startup, VIVO should download, start, and configure Solr, if it has not been configured
    4. System administrators should be able to enable i18n languages via runtime configuration files
    5. VIVO should only load i18n triples that are associated with enabled i18n languages
    6. Developers should be able to use a three-tier build to create a vivo.war for advanced customization
  4. Vitro JMS messaging approaches - redux
    1. Which architectural pattern should we take?
    2. What should the body of the messages be?
  5. Moving tickets forward
    1. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1658
       - back on your plate, Mike Conlon
  6. Who is working on what? - Are there active tickets in-progress?


    1. Expand

      Jira
      serverDuraSpace JIRA
      jqlQueryfilter=15500
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


  7. Incremental development initiatives
    1. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1688
    2. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1751
    3. Integration test opportunities with the switch to TDB - requires startup/shutdown of external Solr ..via Maven
      1. Jira
        serverDuraSpace JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyVIVO-1752

...

  1. Status of In-Review tickets

    Expand

    Jira
    serverDuraSpace JIRA
    jqlQueryfilter=14416
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


Notes 

Attendees

  1. Huda Khan 
  2. Benjamin Gross 
  3. Ralph O'Flinn
  4. Brian Lowe 
  5. Michel Héon
  6. Nicolas Dickner
  7. Don Elsborg
  8. Sacha Jerabek

Internationalization update (Sacha primarily, plus Michel)

  • Proceeding with testing
    • Looking for things that need to be translated
    • Creating new elements in forms; looking for problematic behavior
    • Capability map
    • Selenium tests being developed from scratch (four tests exist)
      • Not based on previous Selenium tests developed by Jim Blake
  • In next two weeks will be working on solutions for more complex syntactic differences between languages where simple string substitution via properties files is problematic.
  • UQAM team also has other responsibilities, so effort will be somewhat limited.
  • Don interested in having capability map be able to traverse links between persons and publications to include concepts linked via publications and not just directly to people.
  • Benjamin: fairly comprehensive suite of Selenium tests already exists, but I had trouble getting them to run.  Should be documented in the release procedure on the wiki.


VIVO installation - vision and requirements

  • 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 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 implmeneting 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.

Draft notes in Google-Doc 

...