Previously Buildship removed its classpath from all of these
launchers. Now it's automatically putting that back in as soon as I
visit each launcher in Eclipse's "Run Configurations" dialog. Not
sure what's going on here, but it certainly seems more sane to me to
assume that the Buildship-computed classpath *is* needed for all of
these. I have an open question on the Gradle discussion forum to try
to understand what's going on here and how to fix it:
<https://discuss.gradle.org/t/launchers-lose-buildship-classpath-on-import-regain-it-later/25641>.
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.
Previously Buildship removed its classpath from all of these
launchers. Now it's automatically putting that back in as soon as I
visit each launcher in Eclipse's "Run Configurations" dialog. Not
sure what's going on here, but it certainly seems more sane to me to
assume that the Buildship-computed classpath *is* needed for all of
these. I have an open question on the Gradle discussion forum to try
to understand what's going on here and how to fix it:
<https://discuss.gradle.org/t/launchers-lose-buildship-classpath-on-import-regain-it-later/25641>.
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.
This change affects both top-level subdirectory names as well as
Eclipse plug-in feature names. Perhaps it would have been possible to
change only the latter, but I don't like the idea of the two being
different.
These name changes fix three Eclipse plug-in warnings of the form:
Illegal value '...-feature' for attribute 'id'.
Legal token characters are "a-z", "A-Z", "0-9", "_". Tokens
must be separated by "."
I'll be the first to admit that I know nearly nothing about Eclipse
plug-in development. If changing these plug-in feature IDs has
broader implications that the automated regression tests won't detect,
then I probably overlooked them too. I would greatly appreciate
skeptical review of this change by someone who knows Eclipse plug-in
development well.
Note that personal Eclipse workspaces may need some manual adjustment
after this change. The three "...-feature" Eclipse projects should be
removed from the workspace, and the three corresponding "..._feature"
Eclipse projects should be added. If you do your git pull using
Eclipse's team features, perhaps it is smart enough to do this for
you? I don't know, but it wouldn't surprise me if fixing things
manually were still needed even in that case.
a) serializable added for use by Android services
b) test classes refactored to allow Android variants to use JUnit 3
2) shrike instrumentation now uses java.lang.instrument
a) refactoring
b) online variants of call graph tracing
now, for me, code works using e44 with maven
dalvik tests refactored for mobile version with android dev tools
IDE tests Eclipse metadata fixed to make e44 work for me
new android entrypoint to fix failure in new droidbench tests
Ben Liblit
Julian Dolby
Manu Sridharan
Julian Dolby
Manu Sridharan