Closed vazexqi closed 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.
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
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.
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.
@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/
We would have to support Indigo at some point anyway. I am fine with this repository restructuring.
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.
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.
@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.
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.
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.
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.