chapter 20 example

Tell us what you think about our book and report any errata. Sample chapters are available at http://www.qualityeclipse.com/

(Note: Previous Editions were called "Eclipse: Building Commercial Quality Plugins")

Moderators: Eric Clayberg, Dan Rubel

chapter 20 example

Postby charlesgodwin » Wed Jul 26, 2006 3:51 am

in Eclipse: Building Commercial Quality Plug-ins, Second Edition Chapter 20, page 728 there is an example a code fragment for a new method getMenuID() to be added to /org.eclipse.ui.workbench/Eclipse UI/org/eclipse/ui/internal/PopupMenuExtender.java

I cannot find the menuID field to return in the current HEAD version of CVS. Has anyone done this successfully? What am I missing? I'm using Eclipse 32. to build and have no problem compiling the project org.eclipse.ui.workbench/
charlesgodwin
 
Posts: 3
Joined: Tue Jul 25, 2006 9:44 am
Location: Ottawa, ON

Re: chapter 20 example

Postby Eric Clayberg » Thu Jul 27, 2006 6:26 am

charlesgodwin wrote:in Eclipse: Building Commercial Quality Plug-ins, Second Edition Chapter 20, page 728 there is an example a code fragment for a new method getMenuID() to be added to /org.eclipse.ui.workbench/Eclipse UI/org/eclipse/ui/internal/PopupMenuExtender.java

I cannot find the menuID field to return in the current HEAD version of CVS. Has anyone done this successfully? What am I missing? I'm using Eclipse 32. to build and have no problem compiling the project org.eclipse.ui.workbench/

The Eclipse API is constantly evolving. In this case, the PopupMenuExtender class has been refactored to eliminate that field. In addition, rather than there being a single menu id, there are now multiple ids. The class now provides a getMenuIds() method, so you don't need to add it (see the comment above that method about the original getMenuId() method added bt Dan). You could add a new getMenuId() method by simply calling the getMenuIds() method and returning its first element.
Eric Clayberg
Software Engineering Manager
Google
http://code.google.com/webtoolkit/download.html

Author: "Eclipse Plug-ins"
http://www.qualityeclipse.com
Eric Clayberg
Moderator
 
Posts: 4503
Joined: Tue Sep 30, 2003 6:39 am
Location: Boston, MA USA

Postby charlesgodwin » Thu Jul 27, 2006 11:16 am

upon further examination of the current CVS code, the entire example was implemented here's the comment
// getContextMenuIds() added by Dan Rubel (dan_rubel@instantiations.com)

so the code changes are already done for 3.2

also the plugin won't run in 3.2 as /com.qualityeclipse.favorites/FavoritesPlugin#isValidProductVersionForIDE() return false when running in 3.2

I think your chapter source code examples need some work if they're to work with 3.2. After all, the Second Edition does say it's updated for Eclipse 3.1/3.2
charlesgodwin
 
Posts: 3
Joined: Tue Jul 25, 2006 9:44 am
Location: Ottawa, ON

Postby Eric Clayberg » Thu Jul 27, 2006 3:37 pm

charlesgodwin wrote:so the code changes are already done for 3.2

Yes. The Eclipse API is constantly evolving. I'm glad to see that Eclipse.org took our suggested changes.

charlesgodwin wrote:also the plugin won't run in 3.2 as /com.qualityeclipse.favorites/FavoritesPlugin#isValidProductVersionForIDE() return false when running in 3.2

Actually, the plugin runs just fine, and the behavior you are seeing (if you are loading the Chapter 20 code) is intentional. You should see basically the same image as shown in Figure 19-15.

If you want to actually use the plugin, load the earlier Chapter 18 code. The mods made in Chapter 19 (and inherited by Chapter 20) are intended to show how to use the preprocessor and how to add logic to make the plugin act differently in different versions of Eclipse. You can easily make the FavoritesPlugin#isValidProductVersionForIDE() method return true by changing the IDE_VERSION_EXPECTED field (on p706) to return new PluginVersionIdentifier(3, 2, 0). You could also modify that method to allow newer versions of Eclipse, but not older versions.

charlesgodwin wrote:I think your chapter source code examples need some work if they're to work with 3.2. After all, the Second Edition does say it's updated for Eclipse 3.1/3.2

The book was completely updated for Eclipse 3.1 & 3.2, and all of the earlier deprecated Eclipse 3.0 code from the first edition was removed. All of the screen shots were also updated to show Eclipse 3.1 or 3.2 (or both when there were differences we wanted to point out).

Which examples need work? In my testing, they all seemed to work fine in both Eclipse 3.1 and 3.2.
Eric Clayberg
Software Engineering Manager
Google
http://code.google.com/webtoolkit/download.html

Author: "Eclipse Plug-ins"
http://www.qualityeclipse.com
Eric Clayberg
Moderator
 
Posts: 4503
Joined: Tue Sep 30, 2003 6:39 am
Location: Boston, MA USA

Postby charlesgodwin » Thu Jul 27, 2006 4:12 pm

for example this code fragment from FavoritesPlugin

Code: Select all
  public static final PluginVersionIdentifier IDE_VERSION_EXPECTED =
      /* $if version == 3.1 $ */
         new PluginVersionIdentifier(3, 1, 0);
      /* $elseif version == 3.0 $
         new PluginVersionIdentifier(3, 0, 0);
      $endif $ */


and

Code: Select all
org.eclipse.core.runtime.PluginVersionIdentifier

is deprecated
charlesgodwin
 
Posts: 3
Joined: Tue Jul 25, 2006 9:44 am
Location: Ottawa, ON

Postby Eric Clayberg » Thu Jul 27, 2006 7:41 pm

charlesgodwin wrote:for example this code fragment from FavoritesPlugin

Code: Select all
  public static final PluginVersionIdentifier IDE_VERSION_EXPECTED =
      /* $if version == 3.1 $ */
         new PluginVersionIdentifier(3, 1, 0);
      /* $elseif version == 3.0 $
         new PluginVersionIdentifier(3, 0, 0);
      $endif $ */


and

Code: Select all
org.eclipse.core.runtime.PluginVersionIdentifier

is deprecated

There is nothing wrong with the above code. It runs fine in every major version of Eclipse currently in use. The use of the PluginVersionIdentifier class is intentional as it is available in Eclipse 3.2 and each major version prior to that.

The entire purpose behind all of the above code is to provide a way to determine the version of Eclipse being used in a version independent way. It is very important that this code work the same way in every major version of Eclipse (from at least v2.1 on).

If you only care about Eclipse 3.2, you would not use any of this code, so it would be a moot point. If you are creating a plugin that needs to run in Eclipse 2.1 (WSAD 5.1), Eclipse 3.0 (RAD 6.0), Eclipse 3.1 and Eclipse 3.2, then you need to use code that works in all of those versions.

Eclipse 3.2 does include a newer mechanism for indentifying the Eclipse version (which is why they deprecated the old version), but that new mechanism isn't available in older versions of Eclipse, so it can't be used for this purpose.

I should also point out that the PluginVersionIdentifier class was actually deprecated in Eclipse 3.2 RC4...more than a month after the Eclipse 3.2 API was supposedly locked down and barely a month before the final release. This was a very late API change that actually broke the Eclipse.org rules (no API changes allowed once the release candidate cycle starts with RC1).

This late API change also occurred after the 2nd edition of our book went to press (so there was no way for us to anticipate that change). Note that the 2nd printing of the 2nd edition of the book (released earlier this month) includes the following added note at the bottom of p706:

In Eclipse 3.2, the PluginVersionIdentifier class has been deprecated and replaced with the org.osgi.framework.Version class. For version checking to work across Eclipse versions, PluginVersionIdentifier should still be used.
Eric Clayberg
Software Engineering Manager
Google
http://code.google.com/webtoolkit/download.html

Author: "Eclipse Plug-ins"
http://www.qualityeclipse.com
Eric Clayberg
Moderator
 
Posts: 4503
Joined: Tue Sep 30, 2003 6:39 am
Location: Boston, MA USA


Return to Book: Eclipse Plug-Ins (3rd Edition)

Who is online

Users browsing this forum: No registered users and 1 guest