Previously this launcher's job was to run "processTestResources" and
any other Gradle tasks needed to create files that Eclipse was
expecting to be available. But we also want to use it to revert the
bad changes that Buildship applies to ".launch" configuration files.
This is a temporary hack to work around
<https://github.com/eclipse/buildship/issues/653>.
Unlike Linux, macOS has no "RPATH" facility for embedding additional
search paths within shared libraries. Instead, we need to set
"DYLD_LIBRARY_PATH" appropriately in the environment. This
environment variable is the macOS analogue of "LD_LIBRARY_PATH" on
Linux.
Note that adding the required path to the "java.library.path" system
property will *not* work. This property only affects where the JVM
looks for shared objects that it is loading directly. This property
does not influence the search for other, transitively-required shared
objects.
Fixes#3.
This fixes the last of our Javadoc warnings without creating a
circular dependency between ":com.ibm.wala.cast:javadoc" and
":com.ibm.wala.cast.js:javadoc". Fixes#4, wherein more details about
this tricky dependency challenge can be found.
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.
Ben Liblit