This lets the "DynamicCallGraphTest" tests pass. The tests in that
class expect to find some element of the classpath that includes the
substring "com.ibm.wala.core.testdata". They then treat that as a
collection of bytecode files to instrument.
Big thanks to Julian for showing me where this exclusion logic lives
in the Maven configuration. There's a "**/*AndroidLibs*.java"
exclusion pattern in the top-level "pom.xml".
It's telling me to remove "eclipse-deps:org.eclipse.core.runtime:+"
and "org.osgi:org.osgi.core:4.2.0" as unused dependencies in the
"com.ibm.wala.cast.java.ecj" subproject. However, these two
dependencies (jar files) are actually needed; compilation fails
without them.
This should give us a set of mutually-consistent jars rather than
picking up random, outdated pieces from Maven Central or wherever else
I could find them. We now also have a single, central place where we
set the Eclipse version that we're building against. Much, *much*
cleaner.
We're not going to attempt macOS Travis CI testing for Maven builds,
because I don't know whether that's even expected to work on the
official WALA master branch. Our main focus here is Gradle.
Note that Travis macOS images do not support JDK switching, so
explicitly selecting the JDK version now becomes part of the
Linux-only configuration.
Travis macOS images also do not support Android as a build "language".
So our Travis CI configuration for Gradle builds now declares that
this is a Java project rather than an Android one. That's OK, though,
because our Gradle scripts already handle downloading the Android SDK;
we don't need Travis CI to do that for us. When building using Maven,
though, we still call this an Android project because Maven builds do
still rely on Travis CI to provide the Android SDK.
squash! Enable macOS (a.k.a. OS X) Travis CI testing for Gradle builds
If future DroidBench changes include things we need, then we can
decide to move to those newer revisions. But we shouldn't allow
DroidBench to change out from under us implicitly whenever someone
commits something new to the DroidBench repository.
This lets us ditch pre-Java-8 in the Gradle build. (The official WALA
master branch recently got rid of pre-Java-8 in its Maven build.)
That, in turn, lets two "com.ibm.wala.dalvik.test" tests pass that
previously were failing. We still have two other failing tests in
that subproject, but this is definitely progress!
Our Gradle build scripts manage the entire process of downloading and
locally installing the appropriate Android SDK. That includes
automatically accepting a license. Maybe some lawyer will throw a fit
about that some day. Until then, I'd rather have a build system that
does everything needed without imposing additional manual steps on
developers.
Previously Buildship removed its classpath from all of these
launchers. Now it's automatically putting that back in as soon as I
visit each launcher in Eclipse's "Run Configurations" dialog. Not
sure what's going on here, but it certainly seems more sane to me to
assume that the Buildship-computed classpath *is* needed for all of
these. I have an open question on the Gradle discussion forum to try
to understand what's going on here and how to fix it:
<https://discuss.gradle.org/t/launchers-lose-buildship-classpath-on-import-regain-it-later/25641>.
This should prepare test resources for all subprojects. A WALA
developer should run this once before running any tests inside
Eclipse. Initially I'd hoped to make this more narrowly focused, but
Eclipse just doesn't have the infrastructure to deal with fine-grained
dependencies. On the other hand, running "./gradlew
eclipsePrepareTestResources" automatically for each build seems like
overkill, and could end up being rather slow. So for now we require
that the developer run this once, by hand.
A cleaned tree is now much closer to a pristine tree that has just
been checked out and never built. The only extra created files that
are left behind are ".gradle", "buildSrc/.gradle", and
"buildSrc/build".
This gets rid of some Eclipse warnings that stem from Buildship being
confused about what it should treat as a source directory if Maven and
Gradle are both being used in the same tree.
Previously we were repeating the library path twice, but that's not
good for long-term maintenance. That being said, extracting this
information from the depths of the native software model seems *far*
more complex than it should be. I had hoped for something nicer in
response to
<https://discuss.gradle.org/t/compute-wl-rpath-flag-suitable-for-native-shared-library/25278>,
but so far there's nothing.
Ben Liblit