...
- Brian Lowe
- Benjamin Gross
- Huda Khan
- Michel HéonNicolas Dickner
- Georgy Litvinov Benjamin Kampe
- Michel HéonWilliam Welling
- Huda Khan
- Alexander (Sacha) Jerabek
- Ralph O'Flinn
Agenda
- Alpha release
- Configuration: context.xml and runtime properties
- Simplifying the changes
- app-name : is it necessary?
- Maven lifecycle semantics : install versus package
- Upgrades from monolingual to multilingual VIVO with ingested data
- Behavior with language-less literals
- Are we satisfied with providing documentation vs. tooling?
- Documentation
- Documentation for multilingual editing?
Jira server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1762 Jira server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1914 - Documentation for multilingual editing
- Existing document: Using VIVO's Internationalization (i18n) Features
- Should it be moved closer to profile editing documentation?
- Expand with text about class/property/faux property label/definition editing?
- Existing document: Using VIVO's Internationalization (i18n) Features
- Other questions
License text: should other changes be considered?Jira server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1965 - Mailing list: Page management entries and /vis request routing.
- Any issues that should be addressed immediately?
- 404 versus invalid parameter errors.
- Future improvements for adding link-only (no content) menu entries.
- Browser plugins that are able to double-submit editing forms? Cause for concern?
How far did we get with this?Jira server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1910 Jira server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1970
- Blockers
Jira server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1956 Jira server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1966 Jira server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1967 Jira server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1969
- Configuration: context.xml and runtime properties
- New developments
Configurable SPARQL queries for comprehensive individual deletion operationsJira server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1962 - Pull request for testing:
- Post-i18n priorities
- VIVO-in-a-box
- Ingest / Kafka
- Advanced Role Management
- Moving Scholars closer to core - next steps
...
Status of In-Review tickets
Expand Jira server DuraSpace JIRA jqlQuery filter=14416 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
Notes
- 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.
- There are problems with these issues...need to figure out where to put properties
- 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
...