Every dependency task listed here is already a dependency of at least
one subproject's "processTestResources" task, and each
"processTestResources" task already depends on the corresponding
"afterEclipseBuildshipImport" task. So listing these tasks here too
is unnecessary.
All Kawa-related downloads now use our existing VerifiedDownload task
class. This gives us Gradle-integrated progress reporting,
incremental build support, build caching, correct dependencies, etc.
Using Kawa to compile Scheme into bytecode now also has proper
dependency management, incremental build support, and build caching.
Same goes for bundling these compiled bytecode files into jar archives
for later use in regression tests.
Also, when downloading kawa-chess, grab a specific commit hash rather
than whatever is the most recent master commit. If this project
changes in the future, we don't want our tests to break unexpectedly.
Perhaps we'd want to pick up any new kawa-chess commits; perhaps not.
Either way, that should be a conscious decision rather than something
that can happen behind our backs.
Someone may have thought that we were ignoring these files, but we
aren't. From what I can tell, for these specific files, revision
tracking is intentional.
This task has an input named "hello_hash.ml", and an output named
"hello_hash.jar". So calling this task "generateHelloHash" is too
vague. Now we call it "generateHelloHashJar" instead.
We now download and verify checksums as a single task, rather than as
two separate tasks. This simplifies other task dependencies, since we
no longer have a checksum-verified "stamp" file separate from the
download itself. Unfortunately the combined task now has a
significant amount of repeated boilerplate. I'm hoping to refactor
that all out into a custom task class, but haven't yet figured out the
details:
<https://github.com/michel-kraemer/gradle-download-task/issues/108>.
We now also use ETags to be smarter about when a fresh download is or
is not actually needed. I think there are still opportunities for
improved caching here, but this is a step in the right direction.
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>.
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".
Some tests in other subprojects do depend on some these extra jar
files. But they can declare those specific dependencies as needed.
Nothing seems to depend on the entire group of extra jars, so it's not
really useful to declare a task that is merely an alias for all of
them.
I was confused about the differences among:
srcDir 'foo'
srcDirs ['foo']
srcDirs = ['foo']
As it turns out, the first two append to the set of source
directories, while the last replaces this set entirely. I generally
want replacement, since WALA's current directory layout never matches
Gradle's assumed defaults.
This task has an input named "hello_hash.ml", and an output named
"hello_hash.jar". So calling this task "generateHelloHash" is too
vague. Now we call it "generateHelloHashJar" instead.
We now download and verify checksums as a single task, rather than as
two separate tasks. This simplifies other task dependencies, since we
no longer have a checksum-verified "stamp" file separate from the
download itself. Unfortunately the combined task now has a
significant amount of repeated boilerplate. I'm hoping to refactor
that all out into a custom task class, but haven't yet figured out the
details:
<https://github.com/michel-kraemer/gradle-download-task/issues/108>.
We now also use ETags to be smarter about when a fresh download is or
is not actually needed. I think there are still opportunities for
improved caching here, but this is a step in the right direction.
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>.
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".