Versions Compared

Old Version 6

changes.mady.by.user Brian Lowe

Saved on

compared with

New Version Current

changes.mady.by.user Brian Lowe

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Brian Lowe
  2. Benjamin Gross 
  3. Huda Khan 
  4. Michel HéonNicolas Dickner 
  5. Georgy Litvinov 
  6. Benjamin Kampe (star)
  7. Michel HéonWilliam Welling 
  8. Huda Khan 
  9. Alexander (Sacha) Jerabek (star)
  10. Ralph O'Flinn  

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. Jira
        serverLYRASIS JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyVIVO-1762
      2. Jira
        serverLYRASIS JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyVIVO-1914
      3. Documentation for multilingual editing
        1. Existing document: How an End-User Can Use the i18n 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. Jira
        serverLYRASIS JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyVIVO-1965
        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. Jira
        serverLYRASIS JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyVIVO-1910
        How far did we get with this?
      5. Jira
        serverLYRASIS JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyVIVO-1970
    5. Blockers
      1. Jira
        serverLYRASIS JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyVIVO-1956
      2. Jira
        serverLYRASIS JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyVIVO-1966
      3. Jira
        serverLYRASIS JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyVIVO-1967
      4. Jira
        serverLYRASIS JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyVIVO-1969
  2. New developments
    1. Jira
      serverLYRASIS JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1962
      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

...

  1. Status of In-Review tickets

    Expand

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


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

...