OHDSI Home | Forums | Wiki | Github

Travis builds failing for R packages using Java

A heads up for everyone using Travis’ continuous integration for R packages that rely on Java (which includes pretty much all our packages): All builds are currently failing because of some issue with Java in the latest image. An issue has been filed with the image maintainers.

@schuemie, is any information in this post helpful? It’s possibl the travis builds migrated to a new OpenJDK recently (or possibly the builds are hosted on Ubuntu) where some .so files that the JVM needs (libjvm.so) is in a different folder (/usr/lib/jvm/java-1.11.0-openjdk-amd64/lib/server)

They suggest adding that to your path and start a new shell, but I’m not sure what that means from the context of a travis build (is there a way to set env variables prior to the travis launch?)

Edit: I think you can disregard this suggestion: I noticed int he log it look slike JDK8 is referenced in the logs, so it wouldn’t be related to OpenJDK 11.

Thanks @Chris_Knoll, that looks like the same problem. I do see in the travis build log that OpenJdk version 8 is installed, not version 11 which was discussed in the post you references, so I’m not sure the same problem applies.

There is also this discussion on the rJava issue tracker that mentions this problem, although the discussion thread seems to suggest this problem is related to an outdated package version, which on travis wouldn’t apply since the latest version is built.

The error message suggests there should be file called config.log that provides more information, but I’m not sure where to find that. It might be helpful to try to run the Ubuntu image manually, so we can debug. Anyone have any suggestions how we can do that?

I also raised the issue with the developer of rJava.

@msuchard has GitHub Actions working as an alternative to travis, as you can see here. Looks pretty neat, and doesn’t have this issue!

GitHub Actions does, of course, have other issues, but in terms of rJava, I have Actions working on windows, macos and linux (cross-platform is a great advantage).

A solution now exists, as described here. I suggest all package owners apply it to their builds.

t