Commit Graph

90 Commits

Author SHA1 Message Date
Julian Dolby d92c732dec fix more osx builds 2018-08-08 21:53:41 -05:00
Julian Dolby e0ad8fd9f7 try Xcode version recommended by Travis 2018-08-03 16:21:03 -04:00
Julian Dolby 25bb519221 set version for macos 2018-08-03 08:21:41 -04:00
Ben Liblit 6be7a1a8a2 Have Travis CI periodically try to build each subproject separately
If Gradle dependencies are set up correctly, then it should be
possible to build any subproject starting with a pristine tree.
These take too long to use for every commit, pull request, etc.  But
running an extensive test like this periodically (e.g., weekly) seems
reasonable.
2018-06-26 09:19:02 -07:00
Ben Liblit 7b96281e77 Bail out if any Travis CI testing commands fail
Previously we could fail some "mvn" stage but keep running anyway,
thereby fooling us into thinking that everything was OK.
2018-04-18 11:29:29 -05:00
Ben Liblit c16f172932 Find Eclipse jars using local Maven mirror of Eclipse P2 repository
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.
2018-04-18 11:29:28 -05:00
Ben Liblit b5cfd56041 Enable macOS (a.k.a. OS X) Travis CI testing for Gradle builds
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
2018-04-18 11:29:27 -05:00
Ben Liblit 3ba04469ad Teach Gradle how to download "/tmp/DroidBench" when needed
One less thing for developers to have to remember to do manually!
2018-04-18 11:29:26 -05:00
Ben Liblit ad60605fe8 In Travis-CI, test Maven and Gradle separately and concurrently
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.
2018-04-18 11:29:24 -05:00
Ben Liblit cebf14c8c5 Run a Gradle build after the Maven build
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.
2018-04-18 11:29:24 -05:00
Ben Liblit 99c2493e37 Revert "Build WALA using Gradle instead of Maven" (#298) 2018-04-18 12:15:56 -04:00
Ben Liblit 4a707d954a Bail out if any Travis CI testing commands fail
Previously we could fail some "mvn" stage but keep running anyway,
thereby fooling us into thinking that everything was OK.
2018-04-17 15:02:36 -05:00
Ben Liblit 5e0e251766 Find Eclipse jars using local Maven mirror of Eclipse P2 repository
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.
2018-04-17 15:02:36 -05:00
Ben Liblit aff4067c39 Enable macOS (a.k.a. OS X) Travis CI testing for Gradle builds
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
2018-04-17 15:02:36 -05:00
Ben Liblit a32a3e3191 Teach Gradle how to download "/tmp/DroidBench" when needed
One less thing for developers to have to remember to do manually!
2018-04-17 15:02:35 -05:00
Ben Liblit 781a448a9a In Travis-CI, test Maven and Gradle separately and concurrently
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.
2018-04-17 15:02:35 -05:00
Ben Liblit 045b9f646c Run a Gradle build after the Maven build
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.
2018-04-17 15:02:35 -05:00
Julian Dolby c8cdaf8616 further refactoring to enable more reuse
eliminate all non-jva 8 compilation
2018-02-05 15:18:37 -08:00
Julian Dolby 8a76b132cd try new way to make javadoc 2017-08-02 14:56:04 +00:00
Julian Dolby 4629f8b9cd see if maven 3.5.0 builds javascript on travis as it does on my laptop 2017-08-02 02:53:01 +00:00
Julian Dolby 3d2cdf76b7 kill debug logging 2017-08-02 02:13:55 +00:00
Julian Dolby 340fb45b85 remove -q for diagnostics 2017-08-02 00:39:51 +00:00
Julian Dolby f094bb7bd0 more combinations 2017-08-02 00:25:27 +00:00
Julian Dolby 725c734b8b swap verify and install 2017-08-02 00:04:38 +00:00
Julian Dolby 93119c7ad4 try javadoc 2017-08-01 23:46:43 +00:00
Julian Dolby e41ff85bbb try javadoc 2017-08-01 23:43:26 +00:00
Julian Dolby df6618ee95 try javadoc 2017-08-01 23:09:35 +00:00
Julian Dolby 31a38e8a4c try javadoc 2017-08-01 22:33:39 +00:00
Julian Dolby 62ca182690 try javadoc 2017-08-01 22:19:37 +00:00
Julian Dolby ab183520da try javadoc 2017-08-01 22:16:32 +00:00
Julian Dolby 9569471d63 try javadoc 2017-08-01 22:15:29 +00:00
Julian Dolby 0e29403485 try javadoc 2017-08-01 22:12:31 +00:00
Julian Dolby 699bc5a308 try javadoc 2017-08-01 22:08:50 +00:00
Julian Dolby 50d0836701 try javadoc 2017-08-01 22:05:32 +00:00
Julian Dolby 9ea26ad22d try javadoc 2017-08-01 22:03:50 +00:00
Julian Dolby 4168547f35 try javadoc 2017-08-01 22:01:38 +00:00
Julian Dolby ec82f6b6e2 try javadoc 2017-08-01 21:57:57 +00:00
Julian Dolby 3dfc70d919 try javadoc 2017-08-01 21:56:21 +00:00
Julian Dolby a3113df645 try javadoc 2017-08-01 21:52:58 +00:00
Julian Dolby bc31c11003 try javadoc 2017-08-01 21:49:44 +00:00
Julian Dolby 63a82aee61 try javascript 2017-08-01 21:45:48 +00:00
Julian Dolby 944f620537 try javascript 2017-08-01 21:44:07 +00:00
Julian Dolby 1e95dbcdd4 try to trigger WALA Client 2017-07-24 14:03:06 +00:00
Julian Dolby 589da154a1 get realpath 2017-06-28 12:52:30 -04:00
Ben Liblit 1bebbeb8e9 Simplify management of virtual frame buffer X server (#181)
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.
2017-05-15 09:02:52 -07:00
Ben Liblit 2a61306338 Download "dx.jar" from Maven, as we already do for "android.jar"
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.
2017-03-16 19:51:11 -05:00
Ben Liblit ffa41a6120 Clone DroidBench in the desired place without pushhd/popd
IMHO this is a simpler way to achieve the desired result.
2017-03-16 19:51:08 -05:00
Ben Liblit 9c6e10cb1c Add trailing newlines, but remove other trailing white space 2017-03-16 19:51:02 -05:00
Manu Sridharan e21ee9f5cf Do a shallow clone of DroidBench
This should (very slightly) speed up build times.
2016-09-20 13:55:47 -07:00
Manu Sridharan a319b3e130 Switch back to using install for jars.
Just running 'verify' won't work since project dependencies are 
resolved via the local maven repository.
2016-05-25 16:30:59 +02:00