Deprecated. This material represents early efforts and may be of interest to historians. It doe not describe current VIVO efforts.
Deprecated. This material represents early efforts and may be of interest to historians. It doe not describe current VIVO efforts.
This document contains instructions on how to upgrade your installation of VIVO from Version 1.5 (or 1.5.1, or 1.5.2) to Version 1.6. This and other documentation can be found on the support page at VIVOweb.org
If you need to do a fresh install, please consult the VIVO Installation Instructions, found on vivoweb.org, or the VIVO Installation Instructions.pdf file located in the doc
directory of the VIVO source code distribution. The installation document also has a list of the required software and versions.
For a description of the release contents see the Release announcement for V1.6.
Create backups of:
The VIVO distribution directory (which contains the source for VIVO 1.5 or VIVO 1.5.1)
The VIVO home directory (pointed to by your deploy.properties file)
The webapps directory in Tomcat
MySQL database (most people use mysqldump to create the backup)
If you have used temporary models in the database to stage ingested data, you will want to clear out any unneeded models that remain listed on the Manage Jena Models
page (under Ingest tools
). This step is especially important if these temporary models contain blank nodes, as this may cause unwanted or duplicate data to appear following the upgrade.The upgrade process is similar to the initial install process with the following exceptions:
distribute
target that will produce a file called distribution.tar.gz
. This compressed archive contains these files:vivo.war
-- a WAR file for the main VIVO application.vivosolr.war
-- a WAR file for the Solr application.solrhome.tar
-- a Solr home directory that is configured for use with VIVO.deploy.properties
file has been split in two. build.properties
contains only the properties that are required for building VIVO. runtime.properties
, which must be created in the Vitro home directory, contains the properties that VIVO uses while running.If you are building to deploy
to Tomcat (as with previous releases), then build.properties
must contain these properties:vitro.core.dir
webapp.name
tomcat.home
vitro.home
-- note that this was vitro.home.directory
in previous releasesdistribute
, the build.properties
file requires only these properties:vitro.core.dir
webapp.name
RemoteAddrValve
that would only permit access from certain IP addresses. Acceptable IP addresses were those which matched the regular expression pattern in the vitro.local.solr.ipaddress.mask
property.This has been removed because:default.log4j.properties
. In release 1.6, this file has been renamed to log4j.properties
. This is so the developers and implementers will know where to look for the file.Note that debug.log4j.properties
, if present, will still override the default.https://wiki.duraspace.org/display/VIVO/Enriching+VIVO+Content+Using+SPARQL+Query+Data+Getters
.themes/wilma/templates subdirectory
.https://wiki.duraspace.org/display/VIVO/Multiple+foaf%3APerson+Profile+Pages
.The RDF files that initialize the data model have moved, in both the distribution and the runtime locations. In the distribution, they have been collected in one place, and reorganized to use a more consistent naming scheme. During the build process, they are copied to a location within the VIVO home directory, instead of residing in the webapp itself.If you have modified these RDF files, or added files of your own, you must adjust to the new locations accordingly.
Old locations of RDF files under [Vitro]/webapp/web or [VIVO]/productMods | New locations of RDF files under [Vitro]/webapp/rdf or [VIVO]/rdf | Comments |
---|---|---|
WEB-INF/ontologies/app/ | rdf/display/firsttime/ | |
WEB-INF/ontologies/app/loadedAtStartup/ | rdf/display/everytime/ | |
WEB-INF/ontologies/app/menuload/displayTBOX.n3 | rdf/displayTbox/everytime/ | Was one file, now a directory |
/WEB-INF/ontologies/app/menuload/displayDisplay.n3 | rdf/displayDisplay/everytime/ | Was one file, now a directory |
WEB-INF/ontologies/user/applicationMetadata/ WEB-INF/init-data/ | rdf/applicationMetadata/firsttime/ | Merged directories |
WEB-INF/ontologies/user/abox/ | rdf/abox/firsttime/ | |
WEB-INF/filegraph/abox/ | rdf/abox/filegraph/ | |
WEB-INF/ontologies/user/tbox/ | rdf/tbox/firsttime/ | |
WEB-INF/filegraph/tbox/ | rdf/tbox/filegraph/ |
If you are using a three-tier build process, you will need to add two lines to the build script to accomodate the RDF files, and the language support (see below) So this:
<patternset id="appbase.patterns"> <include name="src/**/*" /> <include name="lib/**/*" /> <include name="test/**/*" /> <include name="themes/**/*" /> <include name="config/*.properties" /> <include name="config/*.txt" /> <include name="config/jarlist/*.txt" /> <include name="config/solr/*" /> <include name="context.xml" /> </patternset>becomes this:
<patternset id="appbase.patterns"> <include name="src/**/*" /> <include name="lib/**/*" /> <include name="rdf/**/*" /> <include name="languages/**/*" /> <include name="test/**/*" /> <include name="themes/**/*" /> <include name="config/*.properties" /> <include name="config/*.txt" /> <include name="config/jarlist/*.txt" /> <include name="config/solr/*" /> <include name="context.xml" /> </patternset>
example.runtime.properties
.example.developer.properties
.deploy.properties
file into two files, as described below. Store the new build.properties
file in the top level of the VIVO distribution directory. Store the new runtime.properties
file in your VIVO home directory.Properties in build.properties | Properties in runtime.properties |
---|---|
vitro.core.dir vitro.home tomcat.home webapp.name | All other properties from deploy.properties |
Note that vitro.home replaces vitro.home.directory Note that vitro.local.solr.ipaddress.mask is no longer used. |
example.build.properties
and example.runtime.properties
, make copies, and edit them to suit your installation. Remember, the runtime.properties
file goes into your VIVO home directory.The properties below are new to build.properties
. They are optional, so you need not add them unless you want a value other than the default.Property Name | Example Value |
---|---|
Languages (in addition to American English) that will be built into your VIVO site. The languages must be found in the languages directory of the VIVO distribution. See the VIVO Wiki for more information. | |
languages.addToBuild | es_MX |
runtime.properties
. They are optional, so you need not add them, unless you want a value other than the default.Property Name | Example Value |
---|---|
Tell VIVO to generate HTTP headers on its responses to facilitate caching the profile pages that it creates. This can improve performance, but it can also result in serving stale data. Default is false if not set. For more information, see the VIVO wiki page: Use HTTP caching to improve performance | |
http.createCacheHeaders | true |
Force VIVO to use a specific language or Locale instead of those specified by the browser. This affects RDF data retrieved from the model, if RDFService.languageFilter is true. This also affects the text of pages that have been modified to support multiple languages. | |
languages.forceLocale | en_US |
A list of supported languages or Locales that the user may choose to use instead of the one specified by the browser. Selection images must be available in the i18n/images directory of the theme. This affects RDF data retrieved from the model, if RDFService.languageFilter is true. This also affects the text of pages that have been modified to support multiple languages. | |
languages.selectableLocales | en, es, fr_FR |
On the VIVO home page, display a global map highlighting the geographical focus of foaf:person individuals. The default is enabled . | |
homePage.geoFocusMaps | enabled |
MultiViews for foaf:person profile pages. VIVO supports the simultaneous use of a full foaf:Person profile page view and a "quick" page view that emphasizes the individual's own webpage presence. Implementing this feature requires an installation to develop a web service that captures images of web pages or to use an existing service outside of VIVO, usually for a small fee. The default is disabled . | |
MultiViews.profilePageTypes | disabled |
Setting this property causes VIVO 1.6 to produce extended responses to requests for linked data. This provides compatibility with earlier releases. The default is false . Extended linked data is costly, in terms of server resource. Typically, extended linke data contains 50% more information than its non-extended equivalent, and takes 10 times as long to produce. Extended linked data will not be supported in future releases of VIVO. | |
serveExtendedLinkedData | true |
externalAuth.buttonText
is no longer used. You can specify the text of the external login button by adding a property to all.properties
like this:external_login_text = Log in using BearCat Shibboleth3. Apply any previous changes you have made to the new source directory.
Special notes regarding source files4. Apply any previous changes you have made to the RDF initialization files. See the section on the Auto-loaded RDF files above for more details.5. Stop Apache Tomcat and from your VIVO source directory, run ant by typing:
- This process assumes any changes made to the application were made in the source directory and deployed, and were not made directly within the Tomcat webapps directory.
- In many cases, simply copying the modified files from your original source directory will not work since the files on which they are based have changed. It will be necessary to inspect the new source files and add any changes to them at that time.
- NIH-funded VIVO implementations will need to apply the Google Analytics Tracking Code (GATC) to
googleAnalytics.ftl
in the theme:[new_source_directory]/themes/[theme_dir]/templates/googleAnalytics.ftlA samplegoogleAnalytics.ftl
is included in the built-in theme. This file serves only as an example, and you must replace the tracking code shown with your institution's own tracking code. For additional information about the GATC for the NIH-funded VIVO implementation sites and a copy of your institution's tracking code, see the VIVO Google Analytics wiki page.
ant all
6. Start Apache Tomcat and log into VIVO as the root user when the upgrade is completed. Depending on the size of your database, the migration process may take up to several hours. When it is complete, you will see a message in the catalina.log file that the server has started.INFO: Server startup in XXXXX ms7. As root or an administrator, request a rebuild of the Solr search index: Go to the "Site Admin" page and click on "Rebuild Search Index" under the heading "Refresh Content".8. Review the knowledge base migration logs. The knowledge base migration process described in the next section will create logs in a subdirectory of the VIVO home directory:(home directory)/update/logs/knowledgeBaseUpdate.(timestamp).log A log of a summary of updates that were made to the knowledge base. This file should end with "Finished knowledge base migration". If this file contains any warnings they should be reviewed with your implementation team representative to see whether any corrective action needs to be taken.ontologies/update/logs/knowledgeBaseUpdate.(timestamp).error.log A log of errors that were encountered during the upgrade process. This file should be empty if the upgrade was successful. If any errors are encountered you will need to rerun the knowledge base migration.9. Load the About Page .N3 file (optional). Release 1.6 provides an "about VIVO" page that is editable through the GUI, using the Page Management functionality. If your installation has a customized version of the About Page and you do not need to have it accessible via Page Management, then skip this step. Otherwise, here are the instructions for loading the About Page .N3 file:
productMods/WEB-INF/ontologies/app/aboutPage.n3
.[vivo_source_dir]/vitro-core/webapp/web/templates/freemarker/body/termsOfUse.ftlBe sure to make the changes in your source files and deploy them to your tomcat so you don't lose your changes next time you deploy for another reason.
©2013 All Rights Reserved | Powered by VIVO