As everyone should now know, the application process for Google Summer of Code is well underway.  Students are actively putting together their proposals and mentors are busy giving feedback and helping students solidify their ideas.

For those of you who still don’t know what the Google Summer of Code program is, it’s a program put on by Google, in which students are given a stipend to work on open source software.  Eclipse has benefited over the years from great new functionality, exploration of new ideas, and a solid group of students that now understand the Eclipse codebase and processes.

As a former student, I can appreciate how difficult it is to get up-to-speed on an open source project.  Often your good ideas are turned down with statements like “we tried that years ago”, or “that won’t work because of XYZ”.  To help students come up with ideas, many Eclipse enthusiasts have spent sleepless nights putting together our wiki page of ideas.

I’m particularly excited about having somebody extend Zest to include new viewers. Zest is an information visualization toolkit for Eclipse.  Currently it only supports 1 widget, the node-link viewer. I would be great if somebody could contribute new viewers such as Treemaps (nested boxes that can help indicate large areas of a system) or Spacetrees (as you click on nodes, more nodes are presented).  (See the HCIL Lab at Maryland for more great ideas).

It would be really cool to add viewers like this, and then create exemplary tools to demonstrate their use.  For example, we could use a treemap to help locate diskspace issues or a spacetree to help explore p2 repositories.  Browse the wiki, look for ideas, or propose your own.  The deadline is Friday, but if you really want to participate you should have your application in before that.

Tags: soc, zest

As a Riena committer, it’s always nice to see people taking interest in Riena. Feedback  at EclipseCon has been very positive. I was also impressed by  RedView – a UI-generator based on EMF and Riena, which is becoming available soon.

Now James Sugrue wrote “Riena – A New Adventure in Eclipse” over on DZone.

The article introduces Riena, walks you through installation, shows how to create and theme an application and explains Riena’s remote services. Go check it out.

Kind regards,
Elias.

Tags: eclipse ui, rcp, riena

Last Friday, March 27th, Jeff McAffer and I attended the OSGi Tool Summit graciously hosted by LinkedIn:

There were many topics discussed, here are the big ones in my opinion:

Repositories

Now that we have all these bundles everywhere, we have to store them somewhere, right? There is an OSGi RFP 122 out for an OSGi Bundle Repository (OBR) that aims to solve some of this problem. If you’re interested in RFP 122 and OBR, Hal recently blogged about this topic. I expect to see this topic becoming more important in the future as more people adopt OSGi and need a place to store bundles. Also, it’s interesting to note that there are also some commercial offerings that are popping up like Yoxos and some Maven-based solutions.

Application Model

OSGi bundles are great, but sometimes it’s cumbersome working with just bundles. People want to work with a higher level description of bundles. In short, people want a bundle grouping mechanism. I tend to agree that having an ability to group bundles and in Eclipse land we realized this early in the process. At Eclipse, we have developed the concept of features and product definitions to alleviate the pain of managing bundles. In Eclipse 3.5, product definitions were enhanced to support a lot of OSGi use cases like the ability to set start levels and properties. At EclipseSource, we even use product definitions to deploy server-side OSGi applications.

Visualization

People say pictures are worth a thousand words and the OSGi community wants to visualize their bundles. At the summit, we discussed the topic of visualizing bundles and I demonstrated the visualization tooling in PDE:

The PDE Visualization tools allow you to quickly see why you depend on a certain bundle and some other cool things. These tools are just a start and adding support for packages is the next logical step. People also want it easy to see circular dependencies and dependency extent. If you have any ideas on how to improve the visualization tooling within PDE, please file enhancement requests.

Build Consistency

There are many people out there building large scale OSGi-based applications. The experience reports from people were gripes about the difference in headless and IDE environments. It’s simple, people want a consistent OSGi build story when it comes to the IDE and headless.

Visibility Fidelity

The general goal here is to find a way to eliminate any bundle compile and runtime differences. It doesn’t help when at compile time, you have a linear classpath and with OSGi, you have a directed graph classpath. In Eclipse and PDE, we try to enforce classpath visibility by setting access rules on JDT’s excellent compiler.

Version Policies and Management

I always say that without a good versioning story, modularity is worthless. In my opinion, I find it tragic that in the Java community we tend to treat versions as a marketing tool rather than to signify contractual changes. In essence, most people like to bump versions randomly or to beat the version of a competitor’s product. If you look inside the OSGi specification (section 3.6.2), there is very little said on how we should version our bundles and packages. Actually, this is the only thing said:

This is actually not a bad policy. At Eclipse, we build on this policy and treat version numbers as sacred. I encourage anyone buliding OSGi-based applications to review the Eclipse version numbering guidelines. I also had time to demonstrate PDE API Tools which assists developers in API maintenance issues like binary compatibility problems, version number issues and identifying usage of non-API code between bundles:

I plan on blogging about the topic of OSGi and version numbers in a future post since I’m passionate about this topic, so stay tuned!

Developer Use Cases

One of the most important things we did at the tool summit was to formulate OSGi developer use cases. That is, try to trace the activity of a bundle developer from the start of a new project all the way to deployment. By having a set of solid use cases, it will help us see where the holes are in the current tooling.

I believe this was the first time you had the OSGi tooling teams of Netbeans, Eclipse PDE, Sigil, BND, Felix, Maven, OPS4J/PAX, IntelliJ and SpringSouce Tools in the same room. It was great, we didn’t yell at each other like I thought, we actually discussed and debated things. I was also convinced that I should rename PDE to BDE, never use the word ‘plug-in’ and work on making PDE usable by the traditional OSGi community.

In the end, I think the most important outcome of the summit was to bring the right people to the table and start the OSGi tooling discussion. Now that we have done that, expect to see more OSGi tooling collaboration. What do you think is missing from the current tooling story around OSGi?

Tags: OSGi, p2, pde

For simple RCP Applications the Perspective-Switcher widget that ships with Eclipse is overloaded and cumbersome to use.

We are going to get rid of it and replace it with an equivalent menu and/or toolbar for switching perspectives. Both should have an indicator to show which perspective is currently active.

Hiding the Perspective-Switcher

To hide the Perspective-Switcher we go to our ApplicationWorkbenchWindowAdvisor and instruct the IWorkbenchWindowConfigurer to not show the perspective bar.

public void preWindowOpen() {
  IWorkbenchWindowConfigurer configurer = getWindowConfigurer();
   configurer.setShowPerspectiveBar(false);
  // ...
}

 

Using simple commands – not enough

Let’s see how we could contribute a menu / toolbar for switching perspectives. 

The workbench has the command ‘org.eclipse.ui.perspectives.showPerspective’ that can switch to a given perspective. It accepts a parameter ‘org.eclipse.ui.perspectives.showPerspective.perspectiveId’ with the ID of the perspective to show. Optionally a second parameter ‘org.eclipse.ui.perspectives.showPerspective.newWindow’ will open the perspective in a new window if set to ‘true’.

Using  the ‘org.eclipse.ui.menus’ extension point we could contribute a menu with an appropriate <command> for each perspective:

   <extension
         point="org.eclipse.ui.menus">
      <menuContribution
            locationURI="menu:org.eclipse.ui.main.menu">
         <menu
               id="menu.perspectivesStatic"
               label="Perspectives">
            <command
                  commandId="org.eclipse.ui.perspectives.showPerspective"
                  icon="/icons/perspA.png"
                  label="Perspective A"
                  style="radio">
               <parameter
                     name="org.eclipse.ui.perspectives.showPerspective.perspectiveId"
                     value="example.perspectiveswitch.simple.PerspectiveA">
               </parameter>
            </command>
            <!-- repeat --!> 

 

Unfortunately this approach has some drawbacks:

• long xml files
• the list of available perspectives is static – brittle and requires manual maintenance
• it is difficult to indicate which perspective is currently selected

Using dynamic contributions – success

Fortunately the <dynamic> element of  ’org.eclipse.ui.menus’ comes to our rescue. It allows us to contribute a Java class that populates the menu/toolbar on the fly (note: use a separate class for each).

Here’s the <dynamic> element that populates the ‘Perspectives’ menu:

   <extension
         point="org.eclipse.ui.menus">
      <menuContribution
            locationURI="menu:org.eclipse.ui.main.menu">
         <menu
               id="menu.perspectivesDynamic"
               label="Perspectives">
            <dynamic
                  class="example.perspectiveswitch.PerspectiveSwitcherMenu"
                  id="perspectiveSwitcherMenu">
            </dynamic>
      </menuContribution>
   </extension> 

 

The class PerspectiveSwitcherMenu fills the menu on the fly.

We obtain the array of  IPerspectiveDescriptors from the workbench. For each we create a MenuItem with the perspective’s icon and description. Since we created images, we have to dispose them when the menu item is disposed, using a dispose listener. A selection listener is in charge of switching perspective when a menu item is clicked. To provide indication about the active perspective we use the SWT.RADIO style and select one of the menu items. Since the menu is created on the fly each time it is used, we do not need to track the active perspective .

public class PerspectiveSwitcherMenu extends ContributionItem {

public void fill(Menu menu, int index) {
  String activePerspective = getPerspectiveId();
  IPerspectiveDescriptor[] perspectives = PlatformUI.getWorkbench().getPerspectiveRegistry().getPerspectives();
  for(int i = 0; i < perspectives.length; i++) {
    IPerspectiveDescriptor descriptor = perspectives[i];
    // i is used as an item index; 0-n will add items to the top of the menu
    MenuItem item = new MenuItem(menu, SWT.RADIO, i);
    item.setData(KEY_PERSPECTIVE_DESCR, descriptor);
    item.setText(descriptor.getLabel());
    final Image image = descriptor.getImageDescriptor().createImage();
    item.setImage(image);
    item.addDisposeListener(new DisposeListener(){
      public void widgetDisposed(DisposeEvent e) {
        image.dispose();
      }
    });
    item.addSelectionListener(menuListener);
    if(descriptor.getId().equals(activePerspective)) {
      item.setSelection(true);
    }
  }
}

public final boolean isDynamic() {
  return true;
}

 

The toolbar contribution is very similar to the above. Using the ‘org.eclipse.ui.menus’ extension point, we add a <dynamic> element to a <toolbar>. We then implement PerspectiveSwitcherToolbar which extends ContributionItem and overrides the fill(Toolbar, int) to create a toolbar on the fly.

Since the toolbar is visible all the time, we have to track the active perspective, so we can update the ‘selected’ (=depressed) state of the toolbar buttons as necessary. This turned out to be quite tricky. Here’s the solution I went for: a listener tracking the active perspective is installed in each window. If the perspective changes, we look-up the toolbar and update the ‘selected’ state. Since windows may come and go, a second listener keeps track of window creation / disposal and installs / removes the perspective listener as necessary. I wish this was a bit easier – but I’m sharing the below code so you can save a bit of time on this.

Source Download

Download the full code here: example perspective switch.zip

Happy hacking,
Elias.  

PS: If you want to trade off more screen real-estate for a fancier switcher you can use a ‘standalone’ view or a composite that is placed around the page contents. Tom Seidel has the details on his blog.

Tags: eclipse ui, rcp, tips

EclipseCon was quite a blast, lots of amazing talks, some very engaging keynotes and loads of interesting people to meet. One of the neat things about having everyone in one place is that the communication distances are so much shorter. While the internet has revolutionized the way we think about global communication, oftentimes it still doesn’t beat ad-hoc face-to-face conversations. So there was a lot to learn from just listening in on conversations (maybe that’s the secret of twitter) or throwing a question into a room full of highly intelligent people from various backgrounds.

One of these things I learned about was the Eclipse Project Dashboard. This neat little website shows tables and diagrams of all the stuff that is happening in the Eclipse repositories. I have to admit that I am a sucker for diagrams (a common affliction I assume), so this a really great way to get a high-level overview of the ongoing development activities, showing which projects or companies are “hot”, which committers are involved in what projects and a whole bunch of other stuff. And if you want to do some other analysis, there is even RESTful access to the raw data.

The eclipse webmasters have really put a lot of effort into this site, and it’s a shame that it isn’t advertised more. I am sure that it might be interesting for other people as well. So have a look at and see what juicy factoids you can mine.

Tags: commits, dash, eclipse, statistics

The Eclipse Foundation organized an Open Source Strategy Summit in conjunction with EclipseCon, only open to member companies.

The day was packed with interesting presentations on Open Source Business models, Licensing, Open Source case studies and an outstanding presentation by Forrester analyst Jeffrey Hammond. His presentation was on Open Source adoption and his research is very encouraging for the Eclipse community and our EclipseSource offerings. Security, Maintenance and support are key issues when it comes to Open Source adoption, that is exactly what we offer for core Eclipse technologies like Equinox, RCP or RAP. He was comparing the Eclipse community to a shopping mall for customers with anker stores (big players) and boutique stores that together make a very compelling offering. Integration is key as enabler for a best of breed approach. I can really recommend his research on this topic. As an attendee of the summit I am one of the lucky guys getting this slides …

The little presentation on moving RAP to Open Source that I gave is public to everyone and is talking about some of the challenges working in the open – specifically in the context of Eclipse. You can view it online just below.

If you are looking for values of an Eclipse membership – this is the kind of event you should attend next time. We have been already discussing briefly about having an Open Source Strategy Summit at Eclipse Summit in Ludwigsburg this fall. I will sign up for this as soon as it will get announced.

Update: A slightly abriged version of Jeffrey Hammands slides are available from the Open Source Strategy agenda page.

Tags: eclipse, Open Source, rap

This week should be “Go Time” for all students.  This is the week students from across the globe are submitting their applications for Google Summer of Code.   Students, you have until this Friday (April 3rd) to submit your application.  While you may think that’s plenty of time, think again!!!  Some students have already begun submitting their applications, and mentors have already starting reviewing / commenting on them.  If you don’t get your application in early, you are less likely to get any help with it.  (And less likely to find a mentor).  The best advice I can give is to submit early!!!

If you are still looking for ideas, checkout our wiki page.

I can tell you from personal experience that this is a terrific program and it even helped me land a full-time job after graduation.  Internships are great, but Summer of Code will provide you with a portfolio you can present at your next interview.  Just imagine sitting down with a potential employer and faced with the question “What projects have you worked on“?  Imagine being able to say “See that refactoring tool you are using in Eclipse… I wrote that!!!“.  Put that next to the kid who answers… uh… oh… I wrote a bubble sort algorithm in second year that mostly worked.

Google Summer of Code is most definitely For The Win!!!

Tags: eclipse, soc

As I left EclipseCon I was a little surprised there wasn’t the famous +1, -1, 0 buckets outside the Hyatt.  I wanted to cast my vote for the entire conference.  I had a great week and I learned a lot, although there were 2 things that disappointed me.

First, I was not able to attend all the sessions I wanted too.  Maybe others have advice because I don’t know how anyone can attend all the interesting talks / tutorials, meet all the interesting people, hack on cool new ideas, follow twitter (and don’t forget to tweet), read all the blogs (and don’t forget to write), attend the BoFs, settle all your “Beer Dept”, help close down the bar at 1:30am and join the running group at 7:00am.  I did my best, but I probably only accomplished a 10th of what I set out to do.  (If I didn’t repay my Beer Dept to you, please find me at next years EclipseCon).

The second dissapointment was that I had to leave.  Of course I’m happy to be home with my wife and daughters, (and my liver is happy that EclipseCon is over), I would love to spend another week chatting with everyone.   

On my way home I was pleasantly surprised to find myself sitting next to David Green of WikiText fame.  David gave me a tour of his work on WikiText and we spent the 2 hour flight chatting about Eclipse. It was like I got an extra session for free.

So if my only two complaints about the week was that there was too much interesting stuff and eventually I had to go home, I think it is safe to say I would have given the EclipseCon a +1.

Scott Rosenbaum, you did an excellent job of general program chair, and Bjorn, you ran another awesome conference.  It was great to see everyone again!!!

Tags: eclipsecon

The OSGi specification defines a log service (Section 101.1) in the Service Compendium. Like most logging facilities, the log service allows you to specify a message, exception, log level and service reference to be logged. The log service can be acquired using typical OSGi service acquisition mechanisms like a ServiceTracker (see snippet below). However, I highly recommend that you look at using Declarative Services (see Section 112) if you’re working with OSGi services.

public class Activator implements BundleActivator {

	private ServiceTracker logServiceTracker;
	private LogService logService;

	public void start(BundleContext context) throws Exception {
		// create a tracker and track the log service
		logServiceTracker =
			new ServiceTracker(context, LogService.class.getName(), null);
		logServiceTracker.open();

		// grab the service
		logService = (LogService) logServiceTracker.getService();

		if(logService != null)
			logService.log(LogService.LOG_INFO, "Yee ha, I'm logging!");
	}

	public void stop(BundleContext context) throws Exception {
		if(logService != null)
			logService.log(LogService.LOG_INFO, "Yee ha, I'm logging!");

		// close the service tracker
		logServiceTracker.close();
		logServiceTracker = null;
	}
}

Once acquired, you can log messages using the various utility methods LogService:

public interface LogService {
	public static final int	LOG_ERROR	= 1;
	public static final int	LOG_WARNING	= 2;
	public static final int	LOG_INFO	= 3;
	public static final int	LOG_DEBUG	= 4;
	public void log(int level, String message);
	public void log(int level, String message, Throwable exception);
	public void log(ServiceReference sr, int level, String message);
	public void log(ServiceReference sr, int level, String message,
			Throwable exception);
}

The messages are logged as LogEntry objects.

public interface LogEntry {
     public Bundle getBundle();
     public ServiceReference getServiceReference();
     public int getLevel();
     public String getMessage();
     public Throwable getException();
     public long getTime();
}

It’s that simple! The problem with this simplicity is that this type of logging may not be enough for certain projects. The Equinox project at Eclipse has recently graduated an extended log service. The extended log service is similar to the log service we discussed, but there are a few useful additions like named loggers:

public interface ExtendedLogService extends LogService, Logger {
	public Logger getLogger(String loggerName);
	public Logger getLogger(Bundle bundle, String loggerName);
}
public interface Logger {
	public void log(int level, String message);
	public void log(int level, String message, Throwable exception);
	public void log(ServiceReference sr, int level, String message);
	public void log(ServiceReference sr, int level, String message, Throwable exception);
	public void log(Object context, int level, String message);
	public void log(Object context, int level, String message, Throwable exception);
	public boolean isLoggable(int level);
	public String getName();
}

There is also an extended log entry that has information like a logger name and thread-related information:

public interface ExtendedLogEntry extends LogEntry {
	String getLoggerName();
	Object getContext();
	long getThreadId();
	String getThreadName();
	long getSequenceNumber();
}

That’s it!

For those working in RCP or OSGi projects, how are you guys handling logging? Are you using the LogService, Pax Logging or something more exotic?

Tags: equinox, OSGi

The EclipseSource team is enjoying its time at EclipseCon 2009. Here’s a reminder of what our team is talking about today.

Ralf Sternberg and Rudiger Herrmann gave a tutorial about “Single Sourcing RCP and RAP.”

Jeff McAffer and Ian Bull are giving a tutorial on “Understanding and extending p2 for fun and profit.” Come learn about p2!

I’m really excited about Scott Lewis giving a tutorial on “Distributed OSGi – The ECF way.” I hope the tutorial is highly attended given that the ECF implementation of Distributed OSGi is the only complete one (includes discovery) so far and it’s very lightweight!

If you see us around, feel free to stop by and chat with us!

Tags: eclipsecon, OSGi