Address PDE errors

[khatchad]

@khatchad wrote:

another difference could be how our Eclipse settings treat the severity of these errors. For example, they could be set to "ignore" in your workspace. These settings can be global.

In the case of Java compiler warnings, each of WALA's subprojects is configured to use local settings ("Enable project specific settings"), not global ones, for exactly this reason.

The errors you mention are all of type "Plug-in Problem". I suspect that using project specific PDE settings is toggled on/off separately from Java compiler settings. So yes, you are probably right that your workspace has different global settings for plug-in problems than mine does. The next things to do are:

1. Consider each of those errors and decide whether it should be fixed or ignored.
   1. Fix the errors that truly should be fixed.
   2. For errors that should be ignored:
      1. Enable project-specific PDE diagnostic settings.
      2. Set the appropriate items to "Ignore".
      3. Add those PDE settings to Git just as we've already done for JDT (Java compiler) settings.

This is the right thing to do regardless of how one imports projects into Eclipse. @khatchad, do you want to try taking this on and submitting the result in a new pull request? Do you think you understand Eclipse PDE well enough to decide which errors are real problems that should be fixed and which can be safely ignored? (I definitely do not have that knowledge.)

Originally posted by @liblit in https://github.com/wala/WALA/pull/732#issuecomment-605358230

[khatchad]

The errors I am seeing.

[khatchad]

Notes on new WALA architectural decisions.

[msridhar]

Looking at the errors you are seeing, I think it's related to the new WALA architectural decisions. Let me say a bit more about what is going on.

• The com.ibm.wala.ide.* projects still have both Gradle and Maven build files, because we couldn't get the Eclipse Plug-In tests in those projects running under Gradle on CI (they only work in Tycho which is Maven only).
• The way the Maven build works for com.ibm.wala.ide.* is that we first install artifacts for the other WALA projects into the local repository, and then run the Maven build. The Gradle command to install local artifacts and prepare for the Maven build is:

./gradlew prepareMavenBuild publishToMavenLocal -x javadoc

(See here)

After that, if you run mvn clean verify, the relevant artifacts should get copied into the com.ibm.wala.ide.* directories in a way that Eclipse PDE can see them; see this Maven config:

https://github.com/wala/WALA/blob/master/com.ibm.wala.ide/pom.xml#L18-L59

My guess is if you run the above Gradle command followed by the Maven command, your IDE errors might disappear.

We never really tested this with the Eclipse IDE + PDE, so that's why we didn't see this issue. Maybe it's just a documentation problem, or maybe there is a way to make things work more smoothly.

[liblit]

My intent has been to use Gradle‘s eclipse task to pave the way for an error-free workspace after import finishes. A big part of that is handled here:

https://github.com/wala/WALA/blob/096aff828caa2e0f58946fc99b2f96718b41c807/build.gradle#L66-L68

The effect of the above is that during Buildship import, we download/unpack/prepare quite a few other components that will be needed in order for WALA’s Java code to compile or pass its tests.

Here’s another example:

https://github.com/wala/WALA/blob/096aff828caa2e0f58946fc99b2f96718b41c807/com.ibm.wala.dalvik/build.gradle#L92-L94

This gets the Android SDK installed during Buildship import. Without that the com.ibm.wala.dalvik code would show hundreds of Eclipse errors immediately after import finished.

Perhaps we need to push this further? Should we add publishToMavenLocal to synchronizationTasks? That should ensure that the non-PDE jar files are in place before PDE goes looking for them. We could give that a try at least.

[msridhar]

I like that idea. We may also need to call out to mvn clean compile or whatever Maven lifecycle phase will cause the jars to get copied to the right place.

[liblit]

@msridhar wrote:

We may also need to call out to mvn clean compile or whatever Maven lifecycle phase will cause the jars to get copied to the right place.

If all that requires is copying some files from one place to another, then that’s surely something we could implement “natively” in Gradle. Perhaps that would be less clunky than calling out to Maven. It would surely be faster than a full Maven clean compile.

[msridhar]

If all that requires is copying some files from one place to another, then that’s surely something we could implement “natively” in Gradle. Perhaps that would be less clunky than calling out to Maven. It would surely be faster than a full Maven clean compile.

Sure this could work. I'd just like to avoid logic duplication between Gradle and Maven. So hopefully we could remove some of the copying logic from the pom.xml files and stick it in the Gradle prepareMavenBuild task, or something like that.