Eclipse 3.4M2 Released

Eclipse 3.4M2 has been released. The Microsoft Windows edition is available for download from eclipse.org. Same goes for RCP SDK.

As usual you can also find information about the major change in New and Noteworthy.

As we develop as lot of stuff based on RCP and therefore use the PDE extensively, we really like the new plug-in spy. We hope the next releases will see more handy usability enhancements like this. The new editor template support - used for the new SWT expansions - are real time saves too. Making a new template is not all that easy though... maybe something can be done about that?

We look forward to see if M3 is going to bring just as many new exiting features...

Some Differences between IDEs and RCP Applications

One feature of the Eclipse IDE, that most developers seems to like, is the use of perspectives to organize the functionality of the IDE. Perspectives enable you to layout the exact views that is relevant for a specific function or use case. A lot of functionality of the Eclipse platform is used to manage perspectives:

• You can open any perspective in any workbench window.
• You can open any view in any perspective.
• All editors can be shown in all perspectives.
• ...just to name a few features...
  

Where this flexibility is good in an IDE, this is not so in many RCP applications. Here you want a lot more control of the perspectives and the parts that are shown in these perspectives.

The reason for the difference is relatively simple: whereas most developers want to be able to customize their workplace to their specific needs, many enterprises don't want the same freedom for their other office personnel.

Some examples:

• Many RCP applications have multiple workbench windows each with a specific function. Each window might have a number of perspectives, but you don't want to be able to open all perspectives in all windows, only those that are relevant for the specific function of the window. This is not possible with the current perspective chooser - actually it is not even possible to avoid the "open perspective" button or to limit the set of perspectives that are offered in the menu.
• The different perspectives in an RCP application often are much more specialized than in an IDE. E.g. you might have perspectives for contacts, another for mails and yet another for tasks. But there are no way to limit which editors that can be shown in different perspectives. This means the current e-mail messages are shown side-by-side with the open appointments (assuming they both are implemented as editors, which is the "natural" choice). Once an editor has been opened in one perspective, it will be present in all perspectives with an editor area. It might not be too bad for e-mails and appointments, but think of editors with CRM information for different customers and other business specific data...
  
• Again because perspectives in RCP applications are more specific than in an IDE, you also want to limit which views that can be used in different perspectives. But if you want to allow the users to layout the start page (the first perspective), then you cannot limit which views that can be used...

Of cause, all of this can be solved with some custom versions of the relevant RCP actions, but should that really be necessary for all RCP development? Why not make this functionality an integral part of the RCP platform so it is done right and at the same time lower the entry for RCP application development?

Just my input for the upcoming "RCP Experience Workshop" symposium at the Eclipse Summit Europe 2007...

eclipse.dk has been launched

It has taken us some time, but now it is here: eclipse.dk.

Eclipse.dk was created in Marts 2007 as a meeting place for everyone interested in the Eclipse platform.

The purpose of Eclipse.dk is as follows:

1. To promote the knowledge of Eclipse in Denmark.
2. To create networks amongst danish Eclipse-users and developers.
3. To build knowledge on Eclipse in Denmark, especially
   1. In danish institutes of higher education.
   2. Between danish companies developing applications based on Eclipse.
4. Create and maintain a web site on Eclipse for danish users – eclipse.dk.
5. Strengthen the relations between danish and international Eclipse-users and organizations.

The eclipse.dk society has members representing not only vendors of Eclipse-based products and services, but also users of the platform and representatives from institutions of higher education.

On 31. August, Eclipse.dk will have its first major arrangement with a focus on Eclipse 3.3.

To join the eclipse.dk society, use this page.

Please note that the web site is in Danish (almost only).

And the great release wheel starts another turn

Another turn of the great release wheel has just ended successfully with the release of Eclipse 3.3 (Also known as Europa)... and the next turn starts immediately (to be named Ganymede)

The first mile stone, Eclipse 3.4M1, has just been released and it already has several new noteworthy items - see Eclipse 3.4 M1 - New and Noteworthy. My personal favorite is the "Extract Class refactoring", which will extract a number of member variables from an existing class into a new class. It forms a very good basis when an internal 1-to-1 relationship should be changed into a 1-to-n relationship.

If you want to know what is planned for Eclipse 3.4, you can look at the plan for Ganymede (alternatively here) and some of the sub-plans: Team, Text, JDT Core, JDT Text and JDT UI, and others... if you can find them yet. Note that these plans are not expected to become final before late August.

If you want to download Eclipse 3.4M1, use this link - with the new download structure of Eclipse 3.3 it can be a little difficult to find the download pages for specific releases.

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.

A new hidden freature in the PDE editor

Only a few hours ago I reported bug 189102 on bugzilla because I couldn't get the Extension tab of the PDE editor to work.

Basically I wanted to add a sub-element to a decorators extension as shown in the figure on the left. But... there was no sub-elements to add in the pop-up menu.

I have seen that problem a couple of times after I have started to use first 3.3M7 and now 3.3RC1, and this time I had the time to report the problem...

Only a few minutes ago, Mike Pawlowski fra IBM, answered the bug with the following answer:

The decorators schema (/org.eclipse.ui/schema/decorators.exsd)
uses the common expression schema (/org.eclipse.ui/schema/commonExpression.exsd).

In the latter schema, the enablement's grammar is defined as follows:

<!--ELEMENT enablement (and | or | not | objectClass | objectState | pluginState | systemProperty)-->

As a result, the enablement element is only allowed one child. From your screenshot it appears it already has a child.

There was a new feature implemented in the Extensions section that populates the context menu with extension elements based on the corresponding extension point schema. This includes respecting multiplicity constraints.

Since, the enablement element already has one child, no other legal child elements are allowed to be added (feature is working as expected). Delete the child and the context menu will be populated again with a list of valid child elements from the grammar.

Let me know if this is indeed your problem.

And of cause he is right!

This is indeed a very good new feature. It will help solve a problem I have seen in the applications I have helped develop: the user of an extension point does not really adhere to the contract (the schema) and the extension reader fails...

The only down side: now everybody have to be more careful when defining extension points.

Time from when I reported the bug 'till the bug was marked as INVALID: 73 minutes. I wonder how many commercial systems that has that type of responding support.

A Danish Eclipse User Group: eclipse.dk

An Eclipse-only user group has seen the light of day in Denmark. The name of the new user group is eclipse.dk - but please note that the corresponding web site does not function yet.

The new user group - initiated in late April - has active participation from all segments of the Danish Eclipse Ecosystem:

• IBM and BEA represents the product providers
• The RCP Company represents the service providers
• Nordea and Ubiquitech represent the professional users
• DIKU, CBS, RUC and DTU represent the academic users
  

We have many hopes for the new user group. Most notably we hope that the new group can help counter the influence that Microsoft has on the software used on higher education. It would be a sad case, if we cannot get good software engineers with knowledge in Java and possibly Eclipse, just because they only know about .net and C#...

The user group has already invited people to the first after work meeting: 31. May we have gotten two senior engineers from Instantiations to talk about their products - especially the designer tools and the test tools. If you want to participate call Sachin Dhiman on +45 51 92 24 06.

The next major Eclipse technology

The Eclipse Universe includes a very large number of tools and technologies. This is - in one sense - one of the best testaments to the success of the platform. But it is also one of the most infuriating aspects of the platform, when you make a living as a Eclipse service provider.

As an Eclipse service provider, you are always expected to know more about the different Eclipse technologies than what you customers know. And you are expected to be able to give advise about which technologies your customers can/should/could use to solve specific problems.

If you provide training based on the Eclipse platform, some things are obvious. You must have training in RCP as this is the basis of everything else. And we have seen GEF and EMF both being used in many very diverse projects - both are now part of the must-know technologies of the Eclipse Universe and consequently you must have training for these technologies.

But then it becomes much more difficult. Which technology or technologies are next in line?

BIRT? Business Intelligence is a very hot term, and BIRT does support some very basic abilities in this regard, so...?

GMF? Being a combination of EMF and GEF, GMF seems a logical candidate.

Or is it EMFT, M2T, TPTP, ECF, RAP, Higgins or something else?

One can argue for any of these as the next hot technology. It is so difficult to figure out, which Eclipse technology that will be the next important thing, that we must have training for.