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.
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.
The main requirement here is to arrange for the proper classpath
settings when tests are running so that they can find any associated
resources (i.e., other supporting files).
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.
Specifically, we're not really in a position now to deal with
duplicated classes among our dependencies. Maybe we can try harder to
examine those in the future, but for now they are a distraction from
other issues that we can attack more readily.
Some of the linter's checks produce failures (errors) when Gradle
builds the Javadoc documentation. Fixing them isn't really a Gradle
issue, though, so I don't want to deal with them now.
Unfortunately the linter does not reach a fixpoint if you keep trying
to apply its suggestions. If you include "compile
'org.eclipse.core:org.eclipse.core.runtime:3.10.0.v20140318-2214'" in
the dependencies for "com.ibm.wala.ide.jdt", then the linter tells you
that this dependency is unused and can be removed. If you remove it,
then the linter tells you that it should be added. Sigh.
By default, each subproject's Javadoc task depends on the same
subproject's Java compilation task, and uses the same classpath.
Thus, any classes that some Java code uses will also be visible when
building the same Java code's documentation.
In this case, we need to see one of the "com.ibm.wala.core" classes in
order to build the "com.ibm.wala.util" documentation. However, we
cannot have Java compilation of "com.ibm.wala.util" depend on Java
compilation of "com.ibm.wala.core", because that would create a
dependency cycle. So we need to add this as a special dependency just
for the "com.ibm.wala.util" documentation task, and add the
appropriate classpath as well.
I'm quite proud of myself for figuring out how to do this properly.
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
Sungho Lee