Skip to end of metadata
Go to start of metadata


Call-in Information

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

To join the online meeting:


Development Process


(star) Indicating note-taker

  1. Ralph O'Flinn
  2. Kitio Fofack 
  3. Tim Worrall 
  4. Muhammad Javed 

  5. Jim Blake 

  6. Brian Lowe (star)
  7. Don Elsborg
  8. Andrew Woods
  9. Benjamin Gross
  10. Marijane White
  11. Huda Khan
  12. Mike Conlon


  1. 1.10 Release Candidate
    1. Blockers
      1. VIVO-1497 - Getting issue details... STATUS
      2. VIVO-1483 - Getting issue details... STATUS
    2. Release testing
    3. Community messaging
    4. Released projects/artifacts (rel-1.10.0-RC-1)
      1. vivo
      2. vitro
      3. jenatools
      4. sample-data
      5. orcid-api-client
      6. VIVO-languages
      7. Vitro-languages
      8. VIVO-Harverster??
      9. vivo-vagrant??
  2. VIVO Slack... approaching 10k message threshold (at 9.3k)
  3. VIVO Conf unconference session ideas?
    1. Connected VIVOs
    2. Committers gathering
    3. Collaborating across technical initiatives
  4. Next sprint? Sept 17-28
  5. Suggested updates from Michael J. Giarlo
    1. VIVO-1502 - Getting issue details... STATUS
    2. VIVO-1503 - Getting issue details... STATUS
  6. Quick review?  VIVO-1496 - Getting issue details... STATUS


Draft notes in Google-Doc


  • Andrew: pleased to note that the identified blockers have been removed.  So far as I know, we are good to go with the release candidate.

  • Benjamin:  the .pom file for the Jena tools might need to be incremented to the next version, and someone probably needs to upload it to Maven Central.

  • Mike:  Not user-friendly to make someone download Jena tools separately, so yes.  Need to update the jars in Maven Central.

  • Ralph:  need to change .pom file and create new jar files.

  • Andrew:  Benjamin, create pull request?

    • Benjamin:  yes, put part I can’t do is upload jars to Maven Central.

    • Andrew: I can do that and request that your name be added to the list.

  • Mike: I can test when you have it there.

Release testing page

  • Andrew: we need to have green check marks across the board on this page in order to do the release.

  • When you’ve done testing, indicate that you did it, plus any comments about what you saw.  

  • This is a new page, so it probably has bugs.  Also worth making sure that this is the page we want it to be.  

  • Is it comprehensive enough?  Does it cover the functionality?  Is it clear enough that people can actually do the testing?

    • Mike added a whole bunch of content recently that further fleshes this out.

  • Mike: added things based on experience in the past, e.g. performance tests.  Don’t want to go backwards on performance from one release to the next.

  • Andrew: Do we have performance tests?

  • Mike:  We need to generate test data for performance tests, e.g. profile with 1500 publications. Also need tooling.

  • Jim: Developer tools allow you to log the time taken to execute any SPARQL query.

    • Jim will add link to documentation about the developer tool SPARQL query logging.

  • Andrew:  Section on Vagrant testing on wiki page.  What is the scope of the tests we would like to do on the Vagrant environment?

    • There are performance tests listed here and it’s not clear that that’s relevant to Vagrant.

  • Don:  Have Vagrant three-tier build template based on what Ted did.  I can replicate whole CU site in 1.9.3, will continue doing the same for 1.10.

    • Have a complex CONSTRUCT query that we use; can run comparison between 1.9.3 and 1.10.

  • Andrew:  Opportunity to have a whole institutional environment in Vagrant.

    • Will ask Alex about whether the CU data can be shared more broadly for testing elsewhere.

  • Mike:  Expect Vagrant to be our primary VIVO evaluation mode.  

    • Might have to build out data for evaluation purposes.  The more data the better VIVO looks in evaluations

  • Andrew:  Want to have empty Vagrant to test that it works, plus an easy script to populate Vagrant VIVO with data for testing.

  • Andrew:  Clearly would be good if we could add additional links to documentation from the testing plan.

    • In the future, would be good to have these set up as automated integration tests.  Right now just building a manual process.

  • Andrew:  Can I ask for volunteers to do some testing? (In the weeks after the conference)

    • Ralph, Benjamin, Don, Mike, Javed (UI + Jena tools)

    • Jim: interested but not ready to commit until sees how things stand after the conference.

Release artifacts

  • Andrew:  Which artifacts should be part of the release? (Tag in Github, actual release, .pom version updated, etc.)

  • Ralph: I thought it was all of them.

  • Andrew: Is it complete?

    • Some of these have never actually been released, so I wondered if it was appropriate to include them. (E.g. vivo-languages.)  What does that mean?

  • Mike: Never been associated with a release.  They’re on their own. Here we’re trying to take some ownership of it and make sure it works.

  • Andrew:  How do the languages get pulled in or used?

  • Benjamin:  Have to add dependency to your .pom for them to be used.  Have to find the documentation that says how to do it and then add the dependency.

    • There definitely should be a release of the languages for 1.10.  

  • Andrew:  Is ORCID API client tied to the release, or can it have its own numbering scheme?

    • Jim: tied to release of API, not to release of VIVO.

    • Ralph:  ORCID API is on 2.0.  Do we track with that?

      • Jim:  That way lies madness.  

    • Andrew:  0.4 seems reasonable.

  • Andrew:  Creating tars and zips seems to be a manual process.

    • Do we know of any tools, and are they good release artifacts?

  • Mike:  Reasonable goal for 1.10.1 to improve tooling, but don’t let it hold up release.

  • Andrew:  Process will be to examine artifacts for previous releases and replicate their structure.

    • Steps:  Creating release candidate branch, tagging branch, and creating artifacts.  Andrew needs help preparing the release candidate: Ralph will help and expects to get it out sometime today.  Kitio would like to assist. Ralph will be in the dev slack channel.

    • Andrew:  Start to document some of this stuff on the release process document (1d).  Committers, we may need help creating the branches and tags if Ralph and Kitio don’t have permission.

VIVO development workshop

  • Don:  Created Google Drive folder and believe Alex was going to share it.  

  • Prerequisites:  Try to get Vagrant working, and if not get a working Tomcat and Eclipse, also Github account.

  • Work off of forked repo?

  • Questions for Jim and Huda:  What else is there that people want to get out of this workshop? >> Find in Dev Workshop folder in conference folder here:

    • E.g., how to do a three-tier build inside Eclipse?

    • Please put anything else in there that you really want to learn?

  • Don:  Will send out to community mailing list

  • Huda:  If we focus on the participants that probably makes more sense.  Would be good to know if the workshop participants have something they want to work on.

  • Andrew:  In terms of prerequisites, I added a link to Git Desktop.  Bridges the gap for Windows folks with tools like ssh -- often a blocker for this type of workshop.  

  • #dev-workshop Slack channel

Slack topic

  • Skipping for now.

3. Unconference ideas

  • Interconnecting VIVOs?

  • Getting together as committers?

  • Collaborating across initiatives, communicating across channels

  • Huda:  How is this going to be decided?  Will we vote at beginning of conference, or just sign up?

    • Mike:  No one knows.

    • Andrew:  Sounds like people will have the opportunity to pitch their session.  Other than that, not sure.

4. Next sprint in September

5. Local Stanford customizations to roll in if we would like

6. Sample data


  • No labels