Previously Maven did this, but Gradle did not. So Gradle testing
would only succeed if we'd already done a Maven build first. Now
these tests pass in a fresh tree that's never seen a Maven 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.
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.
<https://github.com/liblit/WALA/issues/5> notes that several
subprojects' tests are currently broken under Gradle. I'd still like
to be able to run non-broken tests, though. So here I'm disabling the
failing tests. The intent is to treat these exclusions as a to-do
list. We can remove exclusions as we get the corresponding tests
working. No more exclusions means
<https://github.com/liblit/WALA/issues/5> is fixed.
It's rather slow, adding roughly five seconds to every "./gradlew"
invocation. And the advice it gives might not even be reaching a
fixed point. I like the idea of running the linter as part of CI
testing, but I now think it's overkill to impose on every developer
build.
I don't know whether Windows or MacOS needs anything similar. If they
do, the details will differ, and should be handled by adding suitable
cases to these switch statements.
This partially reverts 72bc456b7. I'm starting to wonder whether the
linter might be driving us in cycles rather than reaching a fixed
point. We should keep our eyes on this.
I'm not actually sure why this archive is needed, except that it is
mentioned in "META-INF/MANIFEST.MF" and "build.properties". If we
eventually stop supporting Maven, then we may be able to discard the
"copyJarsIntoLib" task and the corresponding lines in
"META-INF/MANIFEST.MF" and "build.properties"
This consistently happens when I import WALA as an existing Gradle
project into Eclipse with Buildship. I don't really know what this
change means, or whether it's desirable. For now, I'm going to trust
Buildship and see what happens.
I think these were previously not being compiled at all. Now, with
Buildship generating Eclipse ".project" settings automatically, these
are being processed. In general we don't care much about questionable
code in test data, though.
These settings files currently are generated with an initial timestamp
comment line, which is not something we'd want to track in version
control. Fortunately, the contents of these files are entirely
mundane, so there should be no problem with having Buildship generate
them anew each time a developer imports WALA into Eclipse as an
existing Gradle project.
Apparently Buildship generates these when one uses Import -> Existing
Gradle Project:
<https://discuss.gradle.org/t/buildship-eclipse-plug-in-multiproject-builds/24030/5>.
We can use the Gradle "eclipse" plugin if customizations are
necessary, but my impression is that the intent is to treat ".project"
and ".classpath" as generated files, not sources to be tracked in
source control.
Unfortunately these tests are still not finding their resources
properly at test run time. I don't know why. It seems to have
something to do with how the tests instantiate and use class loaders.
I'm probably going to need expert help with this.
Dependencies are still not set properly here, so you need to have
built the shared library ("./gradlew xlator_testSharedLibrary") before
running the ":com.ibm.wala.cast.test:test" test task. But at least
the tests do now find and load that shared library properly.
Ben Liblit
Sungho Lee