vazexqi / CodingSpectator

Watches and analyzes code edits in the Eclipse IDE non-invasively
http://codingspectator.cs.illinois.edu
Other
20 stars 14 forks source link

Create new patches of CodingSpectator for Eclipse 3.7 Indigo #206

Closed vazexqi closed 13 years ago

vazexqi commented 13 years ago

Just FYI, I was browsing through the "New and Noteworthy" changes and notice that there are several enhancements for JDT in Eclipse 3.7 Indigo. For more information, please refer to this page http://download.eclipse.org/eclipse/downloads/drops/S-3.7M6-201103101119/eclipse-news-M6.html and the links below for prior versions.

I think we can't just reuse our patching mechanism for Eclipse 3.6 because we will not have all the changes that users of Eclipse 3.7 will come to expect. I am also worried that with these changes some of our stuff might not work.

We have to check to see if they have changed any of the internal APIs.

reprogrammer commented 13 years ago

Nick installed CodingSpectator on Eclipse Indigo M7. And, CodingSpectator seemed to work. But, we didn't test it thoroughly. A problem that we noticed was that Eclipse wouldn't allow the user to uninstall CodingSpectator.

reprogrammer commented 13 years ago

I imported CodingSpectator source code into Eclipse 3.7 M7 (Indigo), and I got the following errors in the workspace.

Description Resource    Path    Location    Type
An API baseline has not been set for the current workspace. org.eclipse.jdt.core.manipulation       Unknown Default API Baseline Problem
An API baseline has not been set for the current workspace. org.eclipse.jdt.ui      Unknown Default API Baseline Problem
An API baseline has not been set for the current workspace. org.eclipse.ltk.core.refactoring        Unknown Default API Baseline Problem
An API baseline has not been set for the current workspace. org.eclipse.ltk.ui.refactoring      Unknown Default API Baseline Problem
An API baseline has not been set for the current workspace. org.eclipse.ui.editors      Unknown Default API Baseline Problem
Build path specifies execution environment J2SE-1.4. There are no JREs installed in the workspace that are strictly compatible with this environment.   org.eclipse.jdt.ui      Build path  JRE System Library Problem
Build path specifies execution environment J2SE-1.4. There are no JREs installed in the workspace that are strictly compatible with this environment.   org.eclipse.jdt.ui.tests        Build path  JRE System Library Problem
Build path specifies execution environment J2SE-1.4. There are no JREs installed in the workspace that are strictly compatible with this environment.   org.eclipse.jdt.ui.tests.refactoring        Build path  JRE System Library Problem
Build path specifies execution environment J2SE-1.4. There are no JREs installed in the workspace that are strictly compatible with this environment.   org.eclipse.ltk.core.refactoring        Build path  JRE System Library Problem
Build path specifies execution environment J2SE-1.4. There are no JREs installed in the workspace that are strictly compatible with this environment.   org.eclipse.ltk.ui.refactoring      Build path  JRE System Library Problem
Build path specifies execution environment J2SE-1.4. There are no JREs installed in the workspace that are strictly compatible with this environment.   org.eclipse.text.tests      Build path  JRE System Library Problem
Build path specifies execution environment J2SE-1.4. There are no JREs installed in the workspace that are strictly compatible with this environment.   org.eclipse.ui.editors      Build path  JRE System Library Problem
Dead code   AddMarkerAction.java    /org.eclipse.ui.editors/src/org/eclipse/ui/texteditor   line 179    Java Problem
Dead code   MarkerRulerAction.java  /org.eclipse.ui.editors/src/org/eclipse/ui/texteditor   line 404    Java Problem
EclipseLog cannot be resolved to a type ErrorLogListener.java   /edu.illinois.codingspectator.errorlog/src/edu/illinois/codingspectator/errorlog    line 33 Java Problem
The constructor PlatformLogWriter(null) is undefined    ErrorLogListener.java   /edu.illinois.codingspectator.errorlog/src/edu/illinois/codingspectator/errorlog    line 28 Java Problem
The import org.eclipse.core.runtime.adaptor.EclipseLog cannot be resolved   ErrorLogListener.java   /edu.illinois.codingspectator.errorlog/src/edu/illinois/codingspectator/errorlog    line 11 Java Problem
The method addLogListener(ILogListener) in the type Platform is not applicable for the arguments (ErrorLogListener) EclipseStartup.java /edu.illinois.codingspectator.errorlog/src/edu/illinois/codingspectator/errorlog    line 22 Java Problem
reprogrammer commented 13 years ago

Eclipse Indigo has removed the class org.eclipse.core.runtime.adaptor.EclipseLog. This explains why the error log of CodingSpectator doesn't work for users of Eclipse Indigo.

reprogrammer commented 13 years ago

The migration document is supposed to explain the API changes from Eclipse 3.6 to 3.7. But, this document is empty as of May 16, 2011. The document contains some instructions as of July 2, 2011.

reprogrammer commented 13 years ago

@rajkuma1, @vazexqi, @Wanderer777: Given the insufficient number of external programmers we've recruited so far and the few days left until the release of Indigo, Ralph suggested to add the support for Indigo to CodingSpectator.

I cannot assess how many more participants we will get by supporting Indigo. But, it seems a reasonable action to take in order to recruit more Eclipse developers. I suggest to restructure our repository as follows to separate the Indigo plugins from the Helios ones.

   coding-conventions/
   documentation/
   plug-ins/
     |_helios/
     |_indigo/
Wanderer777 commented 13 years ago

We would have to support Indigo at some point anyway. I am fine with this repository restructuring.

reprogrammer commented 13 years ago

I posted a message to the jdt-ui-dev mailing list asking about their code style convention file. And, one of the members of the JDT team confirmed that many of the source files do not adhere to the formatter.

reprogrammer commented 13 years ago

35f2721a710019306ef1233ba0073ed761ad9cc8 .. f4dbee87cbb6b1086f52180541ac0ab056276e7b patched four plug-ins of Eclipse Indigo without breaking CodingSpectator tests seriously. See issue #258 for more details about some minor failures of the tests.

reprogrammer commented 13 years ago

@vazexqi and I couldn't think of a way to host the two versions of CodingSpectator (Helios, Indigo) at the same update site. So, we will probably have different update sites for Helios and Indigo.

reprogrammer commented 13 years ago

55487192ac850b2da5e5fcd616d5f44eb20fdc38 .. df2df831aca57ebe4cea05b1e720e3b64788a341 added and patched UDC plug-ins for Indigo.

The mechanism for checking out the source code of UDC plug-ins was somewhat different. So, I documented the steps to acquire the source code on the wiki.

reprogrammer commented 13 years ago

I verified that Eclipse prevents the users from using the wrong update site of CodingSpectator. For example, if the user uses the CodingSpectator's update site for Helios on Eclipse Indigo, Eclipse will report an error saying that it cannot proceed with the installation.