Date

Call-in Information

Time: 11:00 am, Eastern Time (New York, GMT-04:00)

To join the online meeting:

Slack

Attendees

(star)  Indicating note-taker

  1. Brian Lowe
  2. Benjamin Gross 
  3. Huda Khan 
  4. Michel Héon 
  5. Georgy Litvinov 
  6. William Welling 
  7. Alexander (Sacha) Jerabek (star)

Agenda

  1. Alpha release
    1. Configuration: context.xml and runtime properties
      1. Simplifying the changes
      2. app-name : is it necessary?
      3. Maven lifecycle semantics : install versus package
    2. Upgrades from monolingual to multilingual VIVO with ingested data
      1. Behavior with language-less literals
      2. Are we satisfied with providing documentation vs. tooling?
    3. Documentation
      1. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
      2. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
      3. Documentation for multilingual editing
        1. Existing document: Using VIVO's Internationalization (i18n) Features
          1. Should it be moved closer to profile editing documentation?
          2. Expand with text about class/property/faux property label/definition editing?
    4. Other questions
      1. Unable to locate Jira server for this macro. It may be due to Application Link configuration. License text: should other changes be considered?
      2. Mailing list: Page management entries and /vis request routing.
        1. Any issues that should be addressed immediately?
        2. 404 versus invalid parameter errors.
        3. Future improvements for adding link-only (no content) menu entries.
      3. Browser plugins that are able to double-submit editing forms? Cause for concern?
      4. Unable to locate Jira server for this macro. It may be due to Application Link configuration. How far did we get with this?
      5. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    5. Blockers
      1. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
      2. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
      3. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
      4. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
  2. New developments
    1. Unable to locate Jira server for this macro. It may be due to Application Link configuration. Configurable SPARQL queries for comprehensive individual deletion operations
        1. Pull request for testing:
          1. https://github.com/vivo-project/Vitro/pull/213
  3. Post-i18n priorities
    1. VIVO-in-a-box
    2. Ingest / Kafka
    3. Advanced Role Management
    4. Moving Scholars closer to core - next steps

Future topics

  1. Vitro JMS messaging approaches - redux
    1. Which architectural pattern should we take?
    2. What should the body of the messages be?
  2. Incremental development initiatives
    1. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    2. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    3. Integration test opportunities with the switch to TDB - requires startup/shutdown of external Solr ..via Maven

Tickets

  1. Status of In-Review tickets

    type key summary assignee reporter priority status resolution created updated due

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Notes

  1. Alpha release and context.xml, runtime properties

UQAM is adapting local installation procedure to use context.xml

Some configs have moved to context.xml from properties, and app  name has moved to context.xml to accommodate different applications names to generate individual log files. 

  1. There are problems with these issues...need to figure out where to put properties
  2. Graham Triggs(?) finds this direction problematic, there is a sequence to deploying war files

        There are intertwined issues related to this deployment change.

WW: suggests rolling back changes to deployment process given current i18n changes, could be complex to revert, but it would be appropriate considering all the ad hoc changes that are being requested.

SJ: conterarguments that undoing deploy changes with war could be overly complicated at this point.

WW: should submit a PR about reverting deploy changes, could be handled outside of Git, outlining what/how it could be possible. Custom web app is built on top of new build and would not work.

BG: are we talking about pulling automatic deploy and the war file approach?

BL: there may be a compromise solution where both war and tar are available, may allow some to avoid compiling, while retaining more flexible options for those using old method

MH: Fuseki uses similar deployment methodology with tar files, may provide some options or ideas for our own deployment. Should explore new approaches before introducing changes to deployment process. 

WW: would be good to consider decoupling configuration from files that can be changed vs files that should not be changed in order to minimize risky procedures. Primary reason for new deploy was to reduce the difficulty of deploying VIVO, and more importantly moving to a more modern containerized methodology - VIVO is not entirely compatible with its own containerization

GL: war file method does decrease difficulty, but as developer prefer to work with source code.

BG: VIVO should be servlet agnostic, VIVO is built to be deployed with Maven in Tomcat, but you could do it otherwise. 

MH: Fuseki makes war files available, and you can do configs as required. If you are a developer you could work with source code, or if you are not interested in that method you can use the war file, there should be a solution that provides a war file for those that need it.

BL: this does seem similar to where VIVO was headed, providing both war and tar methods, however not completely thought out at this point.

MH: two separate projects: deploy from source vs war

WW: there is another complication with integration with GitHub actions continuous build where it is looking for Tomcat. One solution is to automatically generate necessary files while not using them depending on method employed.

WW: several CIs in place to verify steps, biggest changes would be to undo two PRs:

https://github.com/vivo-project/VIVO/pull/197

https://github.com/vivo-project/Vitro/pull/192

And also some tweaks here and there.

BL: do we feel that this is the most reasonable approach?

WW: to summarize:

Create a draft PR that reverts deployment strategy

Minor modifications to docker file

Minor modifications to GitHub workflow

Modification include a switch to have option to deploy with a war file. Include some logic to handle this.

WW: first step we revert, then redo with a process that takes into account these various use cases.

1.b Upgrades from monolingual to multilingual VIVO with ingested data

BL: what to do in cases where no language tags exist at all? Documentation? Provide Sparql queries to update data? How to address these situations? For example tagless English version vs tagged Spanish version. Probably going to see the right things, as default English with no tags should display properly even in a installation where other languages have been added.

GL: what about monolingual non-English environment with no tags, and then add languages with tags?

BL: if untagged is German for example, it should display as default non-indicated language, so it should be fine.

1.c Documentation tasks: work remains to finalize the documentation for using the i18n functionality

BL: a page exists with some documentation that could be expanded, there is no JIRA issue for this as yet

1.d Other questions:

VIVO-1965: should we update copyright holder, license text? Remove reference to Cornell

Other issues from the mailing list: any immediate changes we can do to fix these?

BG: error handling is frustrating for capability map errors (camel case mismatch?)

GL: there are some issues with trying to change homepage entry, generates errors

Draft notes on Google Drive



  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.