It’s that time of year again… we’re getting close to release time at Eclipse!

This year we have a fancy new webpage and logo for Galileo:

We also have a Twitter Birdsnest for the Twitterati out there:

As a reminder, it’s possible to get involved with Galileo before it’s released by helping test Galileo! Eclipse committers appreciate the level of testing from our users, so why not help and do some testing!?

See you June 24th!

Oh also, Friends of Eclipse get access to Galileo earlier. So please donate!

Tags: galileo

Where do you find your bundles?  When a new version of the Eclipse IDE is released do you spend the day (or week) tracking down all your favorite tools?  Of course we have a the Eclipse SDK and a bunch of pre-built packages. We also have the release train with a number of Eclipse projects, but what if you want bundles that are not hosted at Eclipse.org?  What about tools like Checkstyle, ANTRL, and EclEmma?  What bundles do you need for your version of Eclipse?  Do these conflict with existing plugins?

On Thursday, Jordi and I will be presenting a Webinar about Yoxos, our free Eclipse download service.  Yoxos brings together a large collection of Eclipse and 3rd party bundles into one convienent location.  Yoxos started as a Eclipse distribution in 2004 (much like a Linux distribution), but it has grown into a complete provisioning solution for Eclipse users.  Using Yoxos On Demand, you can create a custom distribution from over 4,000 different bundles.

In the webinar, we will talk about how we built Yoxos, how you can construct a custom distribution and share it with co-workers, how you can share your workspace settings with others, and the future of Yoxos.  We will also talk about some exicting new things we are doing at EclipseSource and provisioning in general.

Please join us on Thursday at 11:00am Eastern Time.

Tags: webinar, yoxos

For those of you who don’t know, the Eclipse SDK now ships an implementation of OSGi Declarative Services (DS). I love DS when working with OSGi services and recommend it to people over using the brittle ServiceTracker mechanism. I’m a big proponent of having people learn by example. To help people understand DS a bit more, PDE includes a DS template now. To access the template, simply create a new project and select the template:

Since the template is based on a simple dictionary service, you can fill out some sample words to be in the dictionary:

Once you click finish, PDE will generate a sample project for you. Inside that sample project, there will be a DictionaryService that allows you to register dictionaries (Dictionary):

package org.eclipse.equinox.ds.example;
 
public interface Dictionary {
 
    /**
     * Returns the language of the dictionary
     *
     * @return the language of the dictionary
     */
    public String getLanguage();
 
    /**
     * Check for the existence of a word in the dictionary
     * 
     * @param word the word to be checked.
     * @return true if the word is in the dictionary
     */
    public boolean check(String word);
 
}

You will also notice that the MANIFEST.MF has an entry of ‘OSGI-INF/*.xml’ for the Service-Component header that lists the required DS files. If we take a peak at the component that registers a sample dictionary, it looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="Simple Dictionary">
   <implementation class="org.eclipse.equinox.ds.example.DictionaryImpl"/>
   <service>
      <provide interface="org.eclipse.equinox.ds.example.Dictionary"/>
   </service>
</scr:component>

The Java code equivalent of registering the sample dictionary without DS would look something like this:

...
service = new DictionaryImpl();
// register the service
context.registerService(DictionaryService.class.getName(), service, null);
...

Great, less code we have to write! Now let’s look at a more complicated example of declaring a component that both needs and registers a service:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="Command Provider for Dictionary Service">
   <implementation class="org.eclipse.equinox.ds.example.ServiceComponent"/>
   <service>
      <provide interface="org.eclipse.osgi.framework.console.CommandProvider"/>
   </service>
   <reference bind="setDictionary" cardinality="1..1" interface="org.eclipse.equinox.ds.example.DictionaryService" name="Dictionary" policy="static" unbind="unsetDictionary"/>
</scr:component>

If we had to write this in code, it would involve a ServiceTracker to track the dictionary service, registering our component’s CommandProvider service implementation and code to track dictionary implementations. All in all, it would be quite a chunk of code to keep track of everything. It would get more complicated if we allowed for different cardinality types.

As a reminder, you can also use the DS Tooling in PDE to help craft these component definitions:

Let’s test this example now by launching a new self-hosted instance and checking out the console:

Cool, we can now check for the existence of words in our dictionary using the Equinox console.

Here’s the code used in this example. To test, simply use the ‘Dictionary Example’ launch configuration included:

For a bonus tip, there are console commands to help you debug DS:

---Service Component Runtime---
     list/ls [-c] [bundle id] - Lists all components; add -c to display the complete info for each component;
     use [bundle id] to list the components of the specified bundle
     component/comp <component id> - Prints all available information about the specified component;
     enable/en <component id> - Enables the specified component;
     disable/dis <component id> - Disables the specified component;

Also, I highly recommend using ‘-Dequinox.ds.print=true’ for extra debug information while debugging components that aren’t working like you expect them.

Good luck and I hope this helps! If you want more in depth knowledge of DS, I highly recommend checking out the new Equinox book which showcases an in depth chapter on DS.

Tags: equinox, OSGi, pde

Enabling RCP applications to work with different locales is an essential requirement for server-side Eclipse setups. Multiple users are accessing the same instance of a running application concurrently, and each one should see the UI in his preferred language. Providing a server-side platform, the RAP project faced this problem too and we needed to find solutions to support multiple locales.

Recently I had the chance to discuss with Jeff McAffer how these changes could be integrated into Equinox. There are a number of subtasks to solve:

1. The NLS class must support different locales. Currently, translated strings are kept in static fields.
2. The extension registry must support reading in different locales. Currently, translatable strings in extensions are resolved once at startup and the results are cached.
3. There must be a mechanism to obtain the default locale for the current user and/or API to request a string in a certain locale.

I opened a new bug for the overall multi-locale topic and added patches to these bugs. Currently, comments show that there is no consensus on the suggested solution yet. These patches solve the requirements related to RAP, however, other projects may have different needs. If you have use cases related to multi-locale, please share your comments on the bug.

At any rate, multi-locale support is needed and it would be great to have it even in Eclipse 3.6.

So please comment on the bugs and help to push on this topic!

Tags: nls, OSGi, rap, rcp

Have you had the experience of creating an interesting application, exporting it, generating a p2 repository, connecting to your repository, and *BAM*, nothing there!  The reason this happens is because you likely didn’t categorize your repository. Consider the following:

I have created three fun games for Cell Phones: Tetris, Snakes and Pong.  Of course, to implement these I used eSWT, eRCP, ECF, GEF, EMF, OCL, BIRT and EclipseLink.  I used PDE Build to build these games and published everything to a p2 repository for cell phone users to install.  Here’s the question, when a cell phone user clicks on “Add new applications” what should they see?  Should the list include EMF, BIRT, OCL, etc…?  In Eclipse 3.5, the p2 team has taken the approach that unless you categorize you features, they will not show up in a repository.  This decision gives you complete control over what your users can see. In Milestone 7, the PDE team released some tooling to make categorization easier.

To make use of the new categorization, first create a category file:

From here you can categorize your features in the category definition editor:

Finally, you can select your category file when you export your feature(s)

Now, when you open  your repository, you Installable Units should show up.

In addition to using the PDE Export wizard, you can also use the CategoryPublisher, to inject category descriptions into your existing repositories.  This can be invoked as follows:

-console -consolelog -application org.eclipse.equinox.p2.publisher.CategoryPublisher
-metadataRepository file:/<repo location>/repository
-categoryDefinition /<location>/category.xml

This approach also allows you to separate the categorization of your repository from the Installable Units. This means that you can generate a repository with all your features, and provide different categorizations for different users.

Tags: p2

Ever wanted to get a print out of all components that make up a piece of UI?

This little recursive snippet does that for you.

private void printChildren(Composite composite, int count) {
  StringBuilder spaces = new StringBuilder(count * 2);
  for (int i = 0; i < count * 2; i++) {
    spaces.append(' ');
  }
  for (Control c : composite.getChildren()) {
    System.out.println(String.format("%s%s (%s)", spaces.toString(), c.toString(), c.getLayoutData()));
    if (c instanceof Composite) {
      printChildren((Composite) c, count + 1);
    }
  }
}

Here’s an example of the output:

Composite {} (null)
  Composite {} (null)
    Composite {} (null)
      Composite {} (GridData {horizontalAlignment=Undefined 256 grabExcessHorizontalSpace=true verticalAlignment=GridData.CENTER})
        Label {Subject:} (GridData {horizontalAlignment=SWT.BEGINNING verticalAlignment=GridData.CENTER})
        Label {This is a message about the cool Eclipse RCP!} (GridData {horizontalAlignment=SWT.BEGINNING verticalAlignment=GridData.CENTER})
        Label {From:} (GridData {horizontalAlignment=SWT.BEGINNING verticalAlignment=GridData.CENTER})
        Link {<a>nicole@mail.org</a>} (GridData {horizontalAlignment=SWT.BEGINNING verticalAlignment=GridData.CENTER})
        Label {Date:} (GridData {horizontalAlignment=SWT.BEGINNING verticalAlignment=GridData.CENTER})
        Label {10:34 am} (GridData {horizontalAlignment=SWT.BEGINNING verticalAlignment=GridData.CENTER})
      Text {} (GridData {horizontalAlignment=SWT.FILL grabExcessHorizontalSpace=true verticalAlignment=SWT.FILL grabExcessVerticalSpace=true})

Tags: eclipse, eclipse ui, swt, tips

The other day I announced that new content for the upcoming OSGi and Equinox book is available on Safari Rough Cuts. Cool.

A few people commented on the post and to me privately that they would really like to see certain OSGi Compendium services covered.  Some of the ones mentioned surprised me a little as frankly, I’ve never had cause to use them.  But that’s just me.  What about YOU?

Well, to find out I set up a Doodle poll listing the various services.  Please select the ones you care about or think are interesting/important to have covered in a book.

We are not guaranteeing that all the top picks will be covered as space and time are limited, but your input will definitely help guide us decide what to include and in how much detail.

Tags: OSGi

In previous blog posts I’ve blogged about ECF’s upcoming implementation of RFC 119.

In this post, I would like to jump out of the description of RFC 119 and talk about how the implementation of RFC 119 and ECF remote services fit together…as our implementation of RFC119 is layered on top of the ECF remote services API.

I think of remote procedure call as a leaky abstraction.  For those that haven’t read Joel Spolsky’s The Law of Leaky Abstractions, I highly recommend it.  The reason I would say that it’s a leaky abstraction is that although transparent RPC *looks* like a local method call, it’s clearly not under some situations:

1. The remote call is very slow (or blocks) because of a network problem
2. The remote call cannot complete because the network fails/goes down
3. A parameter to the remote method call cannot be serialized…e.g. trying to make a remote call e.g. like this:  serviceProxy.setWorkspace(IWorkspace workspace…why would passing a workspace to a method call be a problem?)

There are others, but I think these are the most compelling.

Note that all three of the above are runtime issues…i.e. they can happen at runtime for lots of reasons that have nothing to do with the semantics of the RPC itself.  In the case of 1 and 2 they cannot be prevented.  And they are likely to happen for non-trivial procedures.

Note also that since OSGi services are method calls on some service interface (a pojo), that remote services will also have the above issues.  It doesn’t matter what your remoting implementation is, they will all be subject to such problems.  Unfortunately, we (the distribution system implementers) can’t prevent it.

So, to me this means remote procedure call is a leaky abstraction…because even though it looks like normal/local/in memory method call, there are occasions where the ‘truth’ about networks leaks out.

So what to do?   Well, I think there are several things to do, both from the service designer’s viewpoint (i.e. those defining the service to be remoted) and the distribution system implementer’s viewpoint (i.e. people that implement distribution infrastructures…like me).

From the service designer’s viewpoint you could design all of your services to prepared for 1, 2, 3 above…and/or document them as having these properties.  This can/does definately help.  But it is a major pain, and you can end up having services that are more complex (especially if they are used locally as well as remotely).

From the distribution system implementer’s viewpoint I feel one thing to do is what Joel describes in his paper as what TCP did for IP..layering.

That is the approach we’ve taken with implementing RFC 119…as the implementation of transparent remoting as specified in RFC119 is implemented on a non-transparent/explicit remoting API (ECF remote services).  I think this is nice, because it allows/supports more use cases:

“I want to create a simple remote service, as easily as I can and have it work”  (use RFC 119)

“I want to create a remote service that knows about or at least responds properly to the remoting leaks (1, 2, 3, etc above), and not simply crash/block/fail when the service is used”  (use ECF remote services)

So, we’ve implemented RFC119 itself using ECF remote services…and layered transparent remoting on top of a non-transparent remoting runtime API.  This gives choices to both service designers and service consumers about how much they want/need to care about the network leaking into remote OSGi services.   That is, if they care about the leaks they can do something about them, but if they (or the service consumers) don’t care about such leaks they can have a standard way of publishing, discovering, and receiving remote OSGi services.

Tags: api, equinox, OSGi, rfc119

As some of you may know, we are in the process or writing a book on OSGi and Equinox. I just got word from the publisher that the Safari Rough Cuts content has been updated.  This new content includes several new chapters as well as revisions to some of the previous chapters.

Overall the book covers most of the major OSGi features and functions as well as particular value-add bits from Equinox and the Eclipse community. We cover in detail the use of PDE for developing and OSGi-based systems as well as advanced topics like provisioning with p2 and embedding Equinox in app servers using the servlet bridge.

As with the RCP book, we start from scratch and develop a realistic application through the course of the book.  In this case it is Toast, a fleet management system complete with extensible vehicle-side software and a central management server.  Anyone seeing a conference talk from me in the past year has likely seen at least some part of the example.  This approach is cool as it exposes and addresses the issues you have as developers creating such systems.

Check out the new book content and send us your comments.  They really do help.  Also, look for the first batch of content for the 2nd edition of the RCP book on Rough Cuts soon…

As they already did in January – the compeople AG (the folks behind the Riena project) are organizing another Stammtisch on May, 27th. It will take place in their offices in Frankfurt am Main, Germany. As Ian already pointed out, “Germany seems to love their DemoCamp” – but that’s only partly true: We also love our Stammtisch

Ralph will start the official part of the evening with some insights of the Eclipse Foundation and news about the open source community. In addition Ekkehard Gentz will give an introduction to UIs for business applications based on Riena, UML and oAW. And last but not least Jochen Krause will give some cool demos of new features for upcoming RAP 1.2 release.

After so many interesting topics, I hope to have some hot discussions over several cold beverages in the evening. At 7pm they are organizing a get together at the Chicago Meatpackers restaurant. Please let them know, if you participate by sending a mail to Andrea (dot) Drews (at) compeople (dot) de.

Really looking forward to see you there – I think it is going to be a great Stammtisch!

Tags: eclipse, emf, rap, riena, stammtisch