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.
The Eclipse metadata files created in this way are not identical to
those that Buildship would create when importing into Eclipse. The
tests in com.ibm.wala.cast.java.test.JDTJava15IRTests and
com.ibm.wala.cast.java.test.JDTJavaIRTests seem to pass using either
the Gradle-generated or the Buildship-generated versions.
As an aside, if you generate these files using Gradle first and *then*
import using Buildship, you end up with metadata that is identical to
what you would have had if you'd only imported with
Buildship. (There's one irrelevant difference in an unimportant
"<comment>" element.) So Maven's tests should run fine under any
wacky mix of Gradle- and Buildship-generated Eclipse metadata files.
That being said, I recommend not mixing build systems. WALA can be
built using either Maven, Gradle, or Eclipse+Buildship, but you're
probably better off only using one of these in any given build tree.
A mixed tree *should* probably work, but I haven't tested it
thoroughly, and consider better to avoid doing.
Incidentally, if there are other Maven-preparation steps that we'd
like Gradle to automate for us, that can now be done easily by
creating more "prepareMavenBuild" Gradle tasks in other subprojects
and adding the appropriate dependencies. For example, it would be
trivial to use this to automate downloading "/tmp/DroidBench",
installing the Android SDK, etc.
The performance improvement offered by the build cache is modest when
run by Travis CI. This is probably because Travis CI does not keep
the cache on any local machine. Instead, Travis CI uploads the build
cache across a network at the end of each run, then restores the cache
across the network at the start of the next run. So in many cases
we're simply trading network access to original downloads for network
access to the cache image.
Furthermore, it's probably a better test to perform Travis CI testing
jobs from something closer to a clean slate. We really want to know
whether everything builds and passes tests correctly starting from
nothing. We don't want to risk accidentally thinking something would
work simply because we have a cached copy of what it did when it
worked previously.
This should give us a nice build-performance boost, both locally and
in Travis CI. I've used parallel builds routinely for months now, and
they're working fine. Build output caching is newer, but it also
seems to be working well and saves us tremendous time on downloads.
I believe Travis CI jobs get two CPUs by default.
Doing parallel builds regularly is also a good way to help us discover
any build race conditions we may have. There's no guarantee that any
such races will be revealed, but even exposing them
nondeterministically is better than having no possibility of exposing
them at all.
Many tests are excluded until
<https://github.com/liblit/WALA/issues/5> is fixed. But we can at
least have Travis-CI watching over our shoulder to ensure that
no *new* regressions sneak into the tree.
The tests are currently broken due to some sort of problem using class
loaders to find supporting resources. Until I figure this out, better
to have Travis-CI verify only the things we think work.
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.
The Eclipse metadata files created in this way are not identical to
those that Buildship would create when importing into Eclipse. The
tests in com.ibm.wala.cast.java.test.JDTJava15IRTests and
com.ibm.wala.cast.java.test.JDTJavaIRTests seem to pass using either
the Gradle-generated or the Buildship-generated versions.
As an aside, if you generate these files using Gradle first and *then*
import using Buildship, you end up with metadata that is identical to
what you would have had if you'd only imported with
Buildship. (There's one irrelevant difference in an unimportant
"<comment>" element.) So Maven's tests should run fine under any
wacky mix of Gradle- and Buildship-generated Eclipse metadata files.
That being said, I recommend not mixing build systems. WALA can be
built using either Maven, Gradle, or Eclipse+Buildship, but you're
probably better off only using one of these in any given build tree.
A mixed tree *should* probably work, but I haven't tested it
thoroughly, and consider better to avoid doing.
Incidentally, if there are other Maven-preparation steps that we'd
like Gradle to automate for us, that can now be done easily by
creating more "prepareMavenBuild" Gradle tasks in other subprojects
and adding the appropriate dependencies. For example, it would be
trivial to use this to automate downloading "/tmp/DroidBench",
installing the Android SDK, etc.
The performance improvement offered by the build cache is modest when
run by Travis CI. This is probably because Travis CI does not keep
the cache on any local machine. Instead, Travis CI uploads the build
cache across a network at the end of each run, then restores the cache
across the network at the start of the next run. So in many cases
we're simply trading network access to original downloads for network
access to the cache image.
Furthermore, it's probably a better test to perform Travis CI testing
jobs from something closer to a clean slate. We really want to know
whether everything builds and passes tests correctly starting from
nothing. We don't want to risk accidentally thinking something would
work simply because we have a cached copy of what it did when it
worked previously.
This should give us a nice build-performance boost, both locally and
in Travis CI. I've used parallel builds routinely for months now, and
they're working fine. Build output caching is newer, but it also
seems to be working well and saves us tremendous time on downloads.
I believe Travis CI jobs get two CPUs by default.
Doing parallel builds regularly is also a good way to help us discover
any build race conditions we may have. There's no guarantee that any
such races will be revealed, but even exposing them
nondeterministically is better than having no possibility of exposing
them at all.
Many tests are excluded until
<https://github.com/liblit/WALA/issues/5> is fixed. But we can at
least have Travis-CI watching over our shoulder to ensure that
no *new* regressions sneak into the tree.
The tests are currently broken due to some sort of problem using class
loaders to find supporting resources. Until I figure this out, better
to have Travis-CI verify only the things we think work.
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.
Ben Liblit