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.
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.
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.
* Use IAnalysisCacheView instead of AnalysisCache. (#1)
It seems that some additional types need to be changed due to
d24519e974. This may not be inclusive,
however.
* Increase visibility of several methods and constructors.
Used for creating custom contexts and context selectors.
* Ignore the results directory.
* Some generic type fixes in ModRef.java.
This arises at some point during "mvn compile install". I'm not sure
exactly when, but it's definitely automated, and therefore not
appropriate to track in git.
PrunedCFG had been changed to always include an entry and exit node.
The logic for detecting an "empty" ExceptionPrunedCFG inside the PDG
construction code had not been updated appropriately.
We put all the jar files (the testdata jar, JLex, etc.) in the root
directory now, and set up the build.properties so that these jars get
copied into the final plugin jar, making the tests work properly from
maven. We also still copy the jars into the bin/ directory, so the
Eclipse launchers still work.