Eclipse 3.3 released

Fresh from the eclipse-dev mailing-list:

The Eclipse team is pleased to announce that Eclipse 3.3 is now available for download, along with 21 Eclipse Projects, as part of the Europa coordinated release

http://www.eclipse.org/downloads/


The New and Noteworthy is available here.

http://download.eclipse.org/eclipse/downloads/drops/R-3.3-200706251500/whatsnew/eclipse-news.html


We would like to thank other committers, contributors and community members who contributed to the release, especially the following people

http://www.eclipse.org/eclipse/development/acknowledgements_3_3.html

US DoD Gold Disk and Eclipse RCP

A customer ask me today whether Eclipse RCP could pass "US DoD Gold Disk"...

I don't know what this is, apart from some security checks that are performed on an application using a "Gold Disk" (CD?) from US Department of Defense.

Does anybody know, what this is? And whether an Eclipse RCP based application can be expected to pass this sort of certification?

If you don't want to comment on this, please feel free to mail me on tonny.madsen@rcp-company.com.

Eclipse aware Java Obfuscator wanted

It is not the first I have heard this request from a customer: how do we obfuscate the Java code for an Eclipse RCP based application? Because it is not as trivial as it might seem.

There are a number of problem with obfuscation of Java code when using Eclipse RCP:

• Any class that is mentioned in the plugin.xml should either not be obfuscated or the plugin.xml should be changed as well.
• Any Java package that is exported by a plug-in, should not be obfuscated as other plug-ins might depend on these.

Of cause it is possible to built a list of packages and classes that should not be obfuscated by hand, but this is Eclipse - the tool integration platform - so it must be possible to automate this work.

Has anybody done this? Any pointers to obfuscation applications and Eclipse plug-ins will be appreciated.

Using activities for user management

One common requirement from almost all RCP based applications is the ability to restrict parts of the user interface based on the identity of the current user: when the user logs in as the application is started, the current capabilities of the user is typically downloaded from a sign-on server, and now we want to restrict the user interface of the application based on these capabilities.

This blog entry will show how to implement this using activities in Eclipse RCP. A demonstration plug-in is found here.

There seems to be at least a couple of possible solutions based on plug-ins: only install the plug-ins relevant for the user or only load the plug-ins that are allowed for the user. Although this is not all that difficult to implement, it is a rather coarse solution. It is not always the case that the functionality of plug-ins can be divided along the same lines as wanted from the security system. It is similar to using a canon to shoot a mosquito...

A much more elegant solution is to use activities - also known as capabilities - for the job as these can be used completely orthogonal to plug-ins: once the activities can be defined, these can be used to restrict just about any contribution of the interface in any plug-in.

Another very nice property of activities, is the fact the almost all of the implementation is confined to the various plugin.xml files. Only a very small part of the functionality must go into the Java code itself and even that can be limited to the WorkbenchAdvisor or a similar place...

To use activities you must use the following model:

• Activity: A single activity (or capability)
• Category: An arbitrary set of activities - these are only relevant if you expect to expose the Capabilities preference page to the users, which is very unlikely when activities are used in this use case...
• Pattern: A regular expression for the contributions that are managed via an activity
• Manager: The activity manager
• Identifier: A single ID from a specific plug-in

It is possible to assign many different types of contributions to activities, so the contributions are only enabled if the activity is enabled: perspectives, views, editors, wizards, preference pages, menus, toolbars, commands, and actions.

You must go through the following steps to use the activities in your application.

Defining a new activity

To define a new activity you use the following org.eclipse.ui.activities/activity extension:

<extension
 point="org.eclipse.ui.activities">
<activity
   description="The Support Role"
   id="com.rcpcompany.demo.activities.support"
   name="Sample action"/>
</extension>

The ID is normally chosen to make it easy to map the capabilities returned by the sign-on server to the internally used IDs. In this case, we assume that the returned token is "support" so it is just a matter of concatenating two strings :-)

Assigning contributions to activities

This is the difficult part, until you find out how to map the different contributions to the ID scheme used in the activity patterns.

Basically you must add a org.eclipse.ui.activities/activityPatternBinding extension for each item you want to handle. Although it is possible to use regular expressions to match many IDs at once, this can hardly be recommended as this makes it rather hard to assign IDs to the different contributions used in an RCP application.

Given the following definition for a view:

<extension
 point="org.eclipse.ui.views">
<view
   class="com.rcpcompany.demo.ui.views.History"
   id="com.rcpcompany.demo.ui.views.History"
   name="History"/>
</extension>

the following definition is used to restrict access to the view based on whether the activity is enabled:

<extension
 point="org.eclipse.ui.activities">
<activityPatternBinding
   activityId="com.rcpcompany.demo.activities.support"
   pattern=".*/com\.rcpcompany\.demo\.ui\.views\.History"/>
</activityPatternBinding>
</extension>

The IDs to use for different contributions is taken from the id attribute used in the definition elements.

I use one conversion to help avoid some of the work: when a command is used in a org.eclipse.ui.menus/menuContribution/command the id is the same as the command with suffix .mc.something. As in the following example:

<extension
 point="org.eclipse.ui.commands">
<command
   description="Shows the name of the current resource"
   id="com.rcpcompany.demo.ui.commands.showName"
   name="&Show Name">
</command>
</extension>

<extension
 point="org.eclipse.ui.menus">
<menuContribution
   locationURI="menu:file">
 <command
commandId="com.rcpcompany.demo.ui.commands.showName"
id="com.rcpcompany.demo.ui.commands.showName.mc.file">
   <visibleWhen>
...
   </visibleWhen>
 </command>
 <command
commandId="org.eclipse.ui.edit.rename"
id="org.eclipse.ui.edit.rename.mc.file">
 </command>
</menuContribution>
<menuContribution
   locationURI="toolbar:org.eclipse.ui.main.toolbar">
 <toolbar
id="com.rcpcompany.demo.ui.toolbars.main.show">
   <command
 commandId="com.rcpcompany.demo.ui.commands.showName"
 id="com.rcpcompany.demo.ui.commands.showName.mc.toolbar.main.show">
   </command>
 </toolbar>
</menuContribution>
</extension>

<extension
 point="org.eclipse.ui.activities">
<activityPatternBinding
   activityId="com.rcpcompany.demo.activities.support"
   pattern=".*/com\.rcpcompany\.demo\.ui\.commands\.showName(\.mc\..*)?"/>
</activityPatternBinding>
</extension>

Enabling activities

To enable the needed features when the user is logged in, the following code can be used in WorkbenchAdvitor:

@Override
public void initialize(IWorkbenchConfigurer configurer) {
  super.initialize(configurer);

  IWorkbenchActivitySupport activitySupport = configurer.getWorkbench()
    .getActivitySupport();
  IActivityManager activityManager = activitySupport.getActivityManager();

  Set<String> enabledActivities = new HashSet<String>();
  String id = "com.rcpcompany.training.demo.activities.activities." + myRole;
  if (activityManager.getActivity(id).isDefined()) {
    enabledActivities.add(id);
  }

  activitySupport.setEnabledActivityIds(enabledActivities);
}

Please notice the the code tests whether the role exists before using it. If this is not done, an undeclared activity will be enabled and no parts of the interface will be affected.

And the rest...

There are a number of other things to be done as well depending on the actual application:

• If the roles can be updated while the application is running, you must repeat the code above in your listener. Unfortunately, you must also clean up the existing perspectives, views and editors in the workbench. This is particular difficult for editors as this can be dirty or in an inconsistent state where they cannot just be saved...
• If you want to debug what contributions that are visible and not, then use the Capability preference page:
  

  
  <extension
   point="org.eclipse.ui.preferencePages">
  <page        
     category="org.eclipse.ui.preferencePages.Workbench"
     name="Capabilities"
     id="org.eclipse.sdk.capabilities"
     class="org.eclipse.ui.activities.ActivitiesPreferencePage"/>
  </extension>

  Please note that you also need an activity category in this case...
  
• There can be any number of roles enabled at the same time.
• Roles can depend on other roles, so you can have "support manager" that depends on "support".
• A demonstration plug-in is found here.

Translating objectContributions into menuContributions

Maybe it is trivial... but never the less I have just used the better part of a day understanding just why my initial proposal didn't work :-(

Consider the following action definition used in Eclipse 3.2.

<extension
    point="org.eclipse.ui.popupMenus">
  <objectContribution
      adaptable="false"
      id="com.rcpcompany.demo.providers.ui.objectContributions.ires.general"
      objectClass="com.rcpcompany.training.demo.core.IRes">
    <action
        class="com.rcpcompany.training.demo.providers.ui.actions.ShowName"
        icon="icons/ShowName.gif"
        id="com.rcpcompany.demo.providers.ui.actions.showname"
        label="Show Name">
    </action>
    <filter
        name="folder"
        value="true">
    </filter>
  </objectContribution>
</extension>

This definition will add a new action with the text "Show Name" to all popup menus if the current selection contains at least one object of the IRes interface and this object returns true for the folder (using an IActionFilter). It is a rather tense description.

For Eclipse 3.3, this description is spread over a number of extension.

First a commands extension is used to declare the command itself:

<extension
    point="org.eclipse.ui.commands">
  <command
      description="Shows the name of the current resource"
      id="com.rcpcompany.training.demo33.providers.ui.commands.showName"
      name="&Show Name">
  </command>
</extension>

Then the image of the command must be added:

<extension
    point="org.eclipse.ui.commandImages">
  <image
      commandId="com.rcpcompany.training.demo33.providers.ui.commands.showName"
      icon="icons/ShowName.gif">
  </image>
</extension>

The next thing is to add a handler for the command:

<extension
    point="org.eclipse.ui.handlers">
  <handler
      class="com.rcpcompany.training.demo33.providers.ui.handlers.ShowName"
      commandId="com.rcpcompany.training.demo33.providers.ui.commands.showName">
    <enabledWhen>
      <with
          variable="selection">
        <iterate
            ifEmpty="false"
            operator="and">
          <and>
            <instanceof
                value="com.rcpcompany.training.demo33.core.IRes">
            </instanceof>
            <test
                property="com.rcpcompany.isFolder">
            </test>
          </and>
        </iterate>
      </with>
    </enabledWhen>
  </handler>
</extension>

This is where most of the complexity is in the new implementation: the tense declaration from 3.2 is now rather verbose. Having said that, the new notation also allows for much more complicated stuff than what was possible before. Note that the IActionFilter has been replaced with a IPropertyTester - which is very good, as all properties now need not be in a single test object, but can be distributed over any number of o objects.

Last the popup menus must be added to all popup menus:

<extension
    point="org.eclipse.ui.menus">
  <menuContribution
      locationURI="popup:org.eclipse.ui.popup.any">
    <command
 commandId="com.rcpcompany.training.demo33.providers.ui.commands.showName">
    </command>
  </menuContribution>
</extension>

Depending on the small details, there can be some changes to this - e.g. if the command should only be shown when the selection includes the right objects.

So what didn't work? I hadn't added the iterate test declaration! And since my selection actually was a StructedSelection, then the implicit iteration from 3.2 had to be handled explicitly.

Having worked with the new notation for a number of days now, I think the new notation is better than the old notation. If you just use a command in a single place, then the new notation will take longer to use, but if the same command is used in at least a few places, then the new notation is faster. With other words: the basic overhead of the new notation is larger than for the old notation...

Working with the menus extension point

I'm in the process of updating my training materials for the new org.eclipse.ui.menus extension point in Eclipse 3.3. To do that I first have to get acquainted with the new functionality.

The new extension point is basically a replacement of the following extension points from Eclipse 3.2:

org.eclipse.ui.popupMenus/viewerContribution

Used to add an action to a specific popup menu (usually a context menu or a ruler) of a view or editor

org.eclipse.ui.popupMenus/objectContribution

Used to add an action to all popup menus when a specific object type is selected

org.eclipse.ui.actionSets/actionSets

Used to add an action to the top-level menu bar and top-level tool bar

org.eclipse.ui.editorActions/editorContribution

Used to add an action to a specific editor top-level menu and tool bar

org.eclipse.ui.viewActions/viewContribution

Used to add an action to a specific view local menu

The new menus extension point not only replaces these extension points, but also adds the ability to add stuff to the trim areas and to the status line. Adding to the trim areas was difficult in Eclipse 3.2, whereas adding to the status line could only easily be done in the ActionBarAdvisor - which made to difficult to use in applications with multiple plug-ins.

To add stuff to any menu or tool bar in Eclipse 3.3, you basically needs two things:

• The ID of the menu or tool bar.
• A command defined with the commands extension point.

The ID of the top-level menus and tool bars are:

• menu:org.eclipse.ui.main.menu – the top-level menu
• popup:org.eclipse.ui.any.popup – all pop-up menus
• toolbar:org.eclipse.ui.main.toolbar – the top-level tool bar
• toolbar:org.eclipse.ui.trim.command1 – the top left trim area
• toolbar:org.eclipse.ui.trim.command2 – the top right trim area
• toolbar:org.eclipse.ui.trim.vertical1 – the left vertical trim area
• toolbar:org.eclipse.ui.trim.vertical2 – the right vertical trim area
• toolbar:org.eclipse.ui.trim.status – the status line trim area

See MenuUtil for constants.
So... to add a new top-level menu along with a single sample action you get:

<extension
point="org.eclipse.ui.menus">
<menuContribution
  locationURI="menu:org.eclipse.ui.main.menu?after=additions">
<menu
    id="com.rcpcompany.demo.menus33.menus.sampleMenu"
    label="Sample Menu"
    mnemonic="M">
  <command
      commandId="com.rcpcompany.demo.menus33.commands.sampleCommand"
      id="com.rcpcompany.demo.menus33.menus.sampleCommand"
      mnemonic="S">
  </command>
</menu>
</menuContribution>
</extension>

Notice the locationURI above. This specification contains three parts, as described in the extension point documentation:

[Scheme]:[ID]?[ArgList]

• Scheme - The 'type' of the UI component into which the contributions will be added. It may be either "menu", "popup" or "toolbar". While 'popup' is indeed a form of menu it is provided to allow a distinction between a view's 'chevron' menu (for which we use the "menu" scheme) and its default context menu which, by convention, should be registered using the "popup" scheme.
• ID - This is the id of menu or toolbar into which the contributions should be added. By convention views should use their view id as the id of the root of their chevron and default popup menu. Note that there is no explicit distinction between contributions supporting editors and 'normal' contributions into the Menu Menu or Toolbar; both global contributions and editor contributions would use the "org.eclipse.ui.main.menu" id or "org.eclipse.ui.main.toolbar". A special id used with popup:, "org.eclipse.ui.any.popup", is reserved to handle contributions which are candidates to appear on any (top level) context menu. Note that these contributions are expected to implement a 'visibleWhen' expression sufficient to limit their visibility to appropriate menus
• Query - This field allows fine-grained definition of the specific location within a given menu. It has the form "[placement]=[id]" where placement is one of "before" or "after" and the id is expected to be the id of some IContributionItem in the menu.

Nearly all the needed information about the menu item is picked up from the command definition (and optionally from the commandImages extension point) except for the tool tip which for some reason cannot be specified in the command declaration.

If you add anything to any of the top-level tool bars (those with the toolbar scheme), you must remember that these really are cool bars and you must therefore first add a tool bar before you add the command itself:

<extension
point="org.eclipse.ui.menus">
<menuContribution
  locationURI="toolbar:org.eclipse.ui.trim.status?after=BEGIN_GROUP">
<toolbar
    id="com.rcpcompany.demo.menus33.toolbars.sampleToolbar">
  <command
      commandId="com.rcpcompany.demo.menus33.commands.sampleCommand">
  </command>
</toolbar>
</menuContribution>
</extension>

One last thing: Previously it was quite clear that you had to have certain specific stuff in the ActionBarAdvisor: if you wanted to use any of the actions from the ActionFactory, then this must be hard-coded, which for practical reasons meant the menu structure would also be hard-coded.

Not so in Eclipse 3.3: here you can just register the needed actions from the ActionFactory in ActionBarAdvisor.makeActions(IWorkbenchWindow) and then declare the rest in the menus extension point using the proper command IDs. Look in the org.eclipse.ui plug-in for a list of all the defined IDs.

Eclipse Summit Europe 2007 comming up

If you want to follow the preparations for Eclipse Summit Europe 2007, monitor the or the eclipse.eclipsecon newsgroup for the latest news.

If the event is going to be anything like last year in Esslingen, then it is worth your time...

Changes in JFace for Eclipse 3.3 means work for us

Eclipse 3.3 is coming. And it adds a lot of new stuff everywhere. It isn't just Europa with its many new tools and technologies, but also the basic platform. Of those changes I have seen until now, the most important from an RCP point-of-view is in JFace:

org.eclipse.ui.menus extension point

This really will help cleaning up the extension point mess from Eclipse 3.2, although the use of commands, handlers and the corresponding declarations will take some getting used to. There are stil some things that cannot be fully declared so the ActionBarAdvisor has not completely disappeared.

org.eclipse.jface.viewers.ColumnLabelProvider basic label provider

This label provider together with org.eclipse.jface.viewers.TableViewerColumn enable column-specific label providers and editing support. It is going to be nice to be able to create complete repositories of label providers that can be used everywhere.

org.eclipse.jface.window.ToolTip tool tip support

Creating tool tips with an arbitrary content is also very nice in many RCP applications where a rich feed back can be a real time saver for the user.

org.eclipse.jface.viewers.OwnerDrawLabelProvider

This new cell label provider (in the same family as ColumnLabelProvider) allows you to draw a cell explicitly. Unfortunately it cannot be used to add complete SWT Controls in cells...

These changes to the training materials in order to be able to show all the new stuff. Just the above changes, takes 3-4 days of changes (including labs).

So I better get started...

Interesting Interview with Mike Milinkovich

Mike Milinkovich, executive director of the Eclipse Foundation, has recently been interviewed by Joe Winchester from SYS-CON.TV. Here Mike talks about some of the interesting aspects of the Eclipse RCP platform right now. One of the more interesting passages is:

At this year's EclipseCon I felt that the amount of interest in RCP had surpassed the amount of interest in the actual IDE. Do you think this is the case, and if so does this change the dynamics of Eclipse's strategy and direction to become more of a general-purpose application platform and less of a development environment?

Milinkovich: Yes, I agree the Eclipse community and the industry as a whole has moved toward viewing Eclipse as an application platform. We are seeing a lot of interest and adoption of RCP and also projects such as Equinox, RAP, and Higgins. However, this is not new as we have had a conscious strategy to move Eclipse beyond just being a Java IDE for several years now. I believe what we are seeing is quite simply that a number of the newer projects within the Eclipse community are becoming more mature and are enjoying greater interest and adoption as a result. The vision for Eclipse has always been about being a complete platform for software development and I think we are well on the way.

This match what we in The RCP Company hear from our customers: RCP and technologies like GMF, Higgins and BIRT is now so stable that they see no problems in basing their enterprise applications on this platform.

Read the full interview at SYS-CON.TV.

Mylar has been renamed Mylyn

See the following mail from Mik Kersten:

The Mylar project has been renamed! Please see the following for more
information. Also note the new "mylyn-" mailing list addresses and that we
now have a mailing list specific to integrators who are building on and
redistributing Mylar:

https://dev.eclipse.org/mailman/listinfo/mylyn-integrators

Blog entry discussing the rename:

http://tasktop.com/blog/?p=6

FAQ about the rename:

http://www.eclipse.org/mylyn/rename.php

Ask questions and post comments on the following bug report:

191406: rename Mylar project to Mylyn
https://bugs.eclipse.org/bugs/show_bug.cgi?id=191406

Mik

Eclipse 3.3RC4 released

Eclipse 3.3 Release Candidate 4 (RC4) is now available for download from eclipse.org. This drop is being propagated to the various Eclipse mirror sites, which usually takes a day or so.

For people who have already downloaded the integration build with timestamp 200706081718, there's no need to download RC4 - it's the same.

Eclipse 3.3RC3 released

Eclipse 3.3 Release Candidate 3 (RC3) is now available for download from eclipse.org. This drop is being propagated to the various Eclipse mirror sites, which usually takes a day or so.

For people who have already downloaded the integration build with timestamp 200706011539, there's no need to download RC3 - it's the same.