This should help identify cases where the Gradle build only works if
it runs before or after a Maven build. It will also help us recognize
any Maven regressions accidentally introduced by our Gradle work.
Eventually I'll want to swap that order, so that we know that Gradle
builds work even without any help from Maven build setup logic. For
now, though, I just want to test whether the Gradle build works at
all.
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
This should help identify cases where the Gradle build only works if
it runs before or after a Maven build. It will also help us recognize
any Maven regressions accidentally introduced by our Gradle work.
Eventually I'll want to swap that order, so that we know that Gradle
builds work even without any help from Maven build setup logic. For
now, though, I just want to test whether the Gradle build works at
all.
Using the `xvfb-run` script gives us automatic lifetime management for
the virtual X server: it will start before the `mvn` test script and
will terminate when that test script exits. The `xvfb-run` script
also sets `$DISPLAY` properly in the `mvn` test script, so we no
longer need to manage that setting ourselves.
This should make it easier for newcomers to get WALA up and running
from sources. One no longer needs to manually find "dx.jar" using
instructions given at
<http://wala.sourceforge.net/wiki/index.php/UserGuide:Getting_Started#Building_the_code>
or
<https://groups.google.com/forum/#!msg/wala-sourceforge-net/cBYsfEvYVG0/Ua52dyQQU-YJ>.
Those instructions were already out-of-date, anyway.
Given that an official release of "dx.jar" is available in Maven, it
would be nice to have Maven itself manage that dependency.
Unfortunately, it seems that WALA in general does not use Maven for
dependency management. As far as I can tell, the Maven configuration
just calls out to Ant for doing builds, including having Ant download
other needed components. If WALA ever moved to using Maven more
fully, downloading "dx.jar" could easily come along with that.
Ben Liblit
Julian Dolby
Julian Dolby
Manu Sridharan