Some local artists have expressed their excitement with the revitalized Visual Editor (VE) project at Eclipse. I thought that I’d share their artistic expression.

For reasons unknown to me, the artists have opted to remain anonymous…

We came across this interesting quote in the Eclipse Summit Europe surveys:

Ed’s and Rich’s demo of EMF/GMF (domain-specific modeling with the Eclipse Modeling Project) was unbelievable … I couldn’t help having a vision of a cottage where two madly giggling witches dance around a cauldron throwing in OCl, QVT, Ecore, Xpand, etc. while crying “snippet.txt”.

I can’t shake the image of Ed and Rich in witches hats… <giggle, snort>

In my last post on the topic, I hinted that adapters can be used to loosen the coupling in your code and then showed how you could use adapters to add even more coupling in your code. Originally, I had a domain class, Person, that knew how to provide information to the Properties view by virtue of implementing the IPropertySource interface. Then, I “decoupled” the domain class from the interface by instead implementing a getAdapter method that returned an instance of a different class when asked for an adapter of the type IPropertySource. I put “decoupling” in quotes, because this step really does nothing to decrease coupling; all it does is move the code somewhere else, the Person class is still just as tightly coupled to the IPropertySource interface. In fact, it is now also coupled to the IAdaptable interface.

Take a few minutes to familiarize yourself with the previous steps. They’re here and here. I’ll wait…

The next step is to completely decouple the domain class from IPropertySource. To do this, I can change the getAdapter method:

public class Person implements IAdaptable {
	private String name;
	private Object street;
	private Object city;

	public Person(String name) {
		this.name = name;
		this.street = "";
		this.city = "";
	}

	public Object getAdapter(Class adapter) {
		return AdapterManager.getDefault().getAdapter(this, adapter);
	}
	…
}

Previously, the getAdapter method checked the type of the desired adapter and created an appropriate instance (if possible) itself. Now, the method makes a call to the AdapterManager, which can take care of figuring out how to adapt the instance.

For this to work, the adapter manager needs to be told how to adapt the type. This can be done declaratively through the plugin.xml file:

<plugin>
   <extension
         point="org.eclipse.core.runtime.adapters">
      <factory
            adaptableType="org.eclipse.example.Person"
            class="org.eclipse.example.adapters.PersonPropertiesSourceAdapterFactory">
         <adapter
               type="org.eclipse.ui.views.properties.IPropertySource">
         </adapter>
      </factory>
   </extension>
</plugin>

This extension defines an adapter for instances of the org.eclipse.example.Person class. When asked to adapt to the org.eclipse.ui.views.properties.IPropertySource, the PersonPropertiesSourceAdapterFactory should be used. This factory class is defined as such:

public class PersonPropertiesSourceAdapterFactory implements IAdapterFactory {
	public Object getAdapter(Object adaptableObject, Class adapterType) {
		if (adapterType == IPropertySource.class)
			return new PersonPropertySource((Person)adaptableObject);
		return null;
	}

	public Class[] getAdapterList() {
		return new Class[] {IPropertySource.class};
	}
}

The getAdapter method does the heavy lifting and creates the adapter. The getAdapterList returns a list of the types of adapters the factory can create.

Adapter factories can also be registered programmatically using APIs on the AdapterManager class.

With the adapters all safely registered, we can make one more change to our code. When adapters are used, they are usually used in three steps::

1. If the object implements the required interface, use the object
2. If the object implements IAdaptable, call the getAdapter method an use the returned object; if something other than null is answered, use the returned value
3. Get the AdapterManager to try and adapt the object

The final step actually makes the current implementation of getAdapter in the Person class redundant. We can simply remove it, and remove the reference to the IAdaptable interface from the class. That is, the Person class simplifies to:

public class Person {
	private String name;
	private Object street;
	private Object city;

	public Person(String name) {
		this.name = name;
		this.street = "";
		this.city = "";
	}
	...
}

Voila! the domain class is totally decoupled from the adapter type. Instances of the person class, when selected in your favourite view will populate the Properties view.

There’s still a couple of issues to deal with. But this entry’s getting a little long, so we’ll talk about them next time (and I’ll post some example code).

I’ll be honest with you: I’m not sure what “World Tour” means. At present, I’m planning this “Europa” tutorial for EclipseWorld, being held November 6-8, 2007 in Reston, Virginia.

Since I started off with honesty, I may as well continue with it: I’ve been struggling to decide what constitutes a “Europa” tutorial. For the uninitiated, “Europa” is the name we gave to our 2007 release train (the simultaneous release of 21 Eclipse projects). With twenty-one projects involved, you’d think it’d be easy to develop a day of material. And you’d be right. I want, however, the tutorial to capture the essence of Europa. It’d be relatively easy to just throw together a bunch of slides about some of the projects and do some exercises involving the technology. To some extent, I’m going to do that.

I’m planning to start by discussing what Eclipse means to me. I give this sort of talk pretty often, and I think it adds a lot of value. It’s certainly the case that—every time I present it—I tell everybody something that they didn’t know. I think it sets the stage for a discussion of just what the heck Europa is. I’m going to talk about the value of the release train and describe each of the projects (briefly, there’s only so much territory that can be covered in a day). I intend to spend some time talking about how projects get involved in the release train and the obligations that come along with participation. I intend to talk a little about the IP due diligence process at Eclipse and how it relates to Europa.

I have a couple of exercises planned. I’ll expose attendees to some of the new features in Eclipse 3.3. Mylyn is going to be part of it. My main focus, however, will be about using Eclipse technology as a basis for building applications. We’ll spend a little time going through some RCP/Equinox stuff and take a look at how some of the projects you may not hear that much about can really help. I have opted to not include EPP as part of this run of the tutorial.

I’ve been using Ubuntu Linux for a few months and am generally happy with it. It’s not perfect, but it’s very good. I’ve become a bit of a Linux apologist lately. I find myself apologising for the fact that my laptop doesn’t easily connect to external monitors and projectors. I apologise that my microphone stopped working after I suspended. Even still, I have quite enjoyed the Linux experience and intend to continue with it.

It’s certainly the case that there is more good than bad. Eclipse runs great on Ubuntu. My dual-core Dell Latitude D820 provides more than enough processing power for me to run sometimes three or four different Eclipse workspaces without breaking a sweat.

I’m looking forward to tomorrow’s release of Ubuntu 7.10 “Gutsy Goose Gibbon” which promises to fix my little external monitor problem and more. I’ll let you know how it turns out.

Look who’s given Eclipse some love…

Months ago, I started a series based on a 2002 blog posting about Eclipse titled “Ten Reasons to Use Eclipse”. As of July, I’ve managed to get through first eight reasons (the previous entry is here). Today, I’m going to look at reason number nine: Team Development

Eclipse is designed to successfully interact with any software configuration management system. The default Eclipse environment is fully integrated with CVS, the standard in open source development: GUI actions give access to most CVS operations – update, commit, diff, merge, patch, etc. The diff tool is spectacular: Java-aware, it can diff specific Java elements individually, e.g. method by method.

But plug-ins already exist for most other SCM systems, such as ClearCase, Perforce, and numerous others. While some are still undergoing heavy development, the strong pressure created by the multitude of Eclipse users all but guarantees they’ll reach production quality soon.

Eclipse integration with SCMs has envolved quite a lot, and is still top-notch. The New and Noteworthy document for Eclipse 3.3 lists many new features in the platform related to the team development, compare, and CVS. A quick look at Eclipse Plug-in Central’s Team Development page reveals that there are dozens of plug-ins for integrating various SCM products with Eclipse. Clearly there is a lot of interest in integrating with Eclipse.

Out of the box, the Eclipse SDK and the various Eclipse IDEs that you can download from eclipse.org all support CVS. Other distributions of Eclipse, like Yoxos and EasyEclipse include Subversion support.

Of course any discussion about team development must include Mylyn. Strictly speaking, Mylyn provides a task-focused experience to Eclipse, but that task focus also provide great team integration with task repositories (like Bugzilla) that allow developers to communicate and share task contexts. There’s also the Eclipse Communication Framework (ECF) which intregrates instant messaging, workspace and editor sharing, IRC, and more directly into the Eclipse environment.

Eclipse provided great support for team development in 2002. It’s only gotten better since then.

I’ve posted a podcast that I recorded last week with Alexey Aristov, co-project lead of the proposed Open Financial Market Platform (OFMP) project. In this podcast, Alexey discusses the history and nature of the project, some of the challenges that lay ahead, and the results of the workshop held on this topic at Eclipse Summit Europe (ESE).

The podcast should be available on the Eclipse Live podcast feed sometime early tomorrow. In the meantime, you can listen to it here.

In my last installment, I showed how—by making a domain class implement IPropertySource and (naturally) implementing the methods required by that interface—you can expose properties from a domain class that can be viewed and modified by the Properties view. In that posting, I suggested that implementing IPropertySource introduces a tight coupling between the model and view and hinted that such a tight coupling was a bad thing.

Tight coupling is bad because it tends to make things less flexible. Sure, we can look at the properties of our domain object, but what happens when we want to participate in other interactions? Do we just implement another interface? And another? Tight coupling makes reuse harder as well. Tightly coupling our domain class with the IPropertySource interface makes it so that our domain class can’t exist without that interface (and all the other types packaged along with it, plus those bits referenced by all those types, …).

Eclipse provides an adapter framework that can be used to solve this problem by decoupling the domain class from the view-specific code required to make the Properties view work.

The first step is to remove the IPropertySource behaviour from the domain class:

...
public class Person implements IAdaptable {
	private String name;
	private Object street;
	private Object city;

	public Person(String name) {
		this.name = name;
		this.street = “”;
		this.city = “”;
	}

	public Object getAdapter(Class adapter) {
		if (adapter == IPropertySource.class) return new PersonPropertySource(this);
		return null;
	}

	// Getter and setter methods follow…
	…
}

We move the IPropertySource behaviour to the PersonPropertySource class:

...
public class PersonPropertySource implements IPropertySource {
	private final Person person;

	public PersonPropertySource(Person person) {
		this.person = person;
	}

	public Object getEditableValue() {
		return this;
	}

	public IPropertyDescriptor[] getPropertyDescriptors() {
		return new IPropertyDescriptor[] {
				new TextPropertyDescriptor("name", "Name"),
				new TextPropertyDescriptor("street", "Street"),
				new TextPropertyDescriptor("city", "City")
		};
	}

	public Object getPropertyValue(Object id) {
		if ("name".equals(id)) return person.getName();
		else if ("street".equals(id)) return person.getStreet();
		else if ("city".equals(id)) return person.getCity();
		return null;
	}

	public boolean isPropertySet(Object id) {
		return false;
	}

	public void resetPropertyValue(Object id) {
	}

	public void setPropertyValue(Object id, Object value) {
		if ("name".equals(id)) person.setName((String)value);
		else if ("street".equals(id)) person.setStreet((String)value);
		else if ("city".equals(id)) person.setCity((String)value);
	}

}

The Property view goes through a few steps to sort out how it’s going to display properties. First, it determines whether or not the selected object implements the IPropertySource interface. If it does (as it did in my previous entry), it uses the selected object directly (after casting it to IPropertySource). If that check fails, the Property view then determines whether or not the selected object implements the IAdaptable interface (highlighted in the Person class). If the selected object is adaptable, it is asked—via the getAdapter method—for an adapter with the IPropertySource type. The getAdapter method either returns an object of the appropriate type or null. If the method returns an adapter, it is used by the Property view to gather properties. Our implementation of adapter fits this bill and so is used.

The astute reader will notice that this really doesn’t do very much to actually weaken the coupling between the domain class an IPropertySource. In fact, the coupling is just as strong. Even worse, we’ve actually introduced a tight coupling to another type (IAdaptable). We’ll fix this problem in the next installment…

I spoke with Yves Yang today at the Eclipse: Now You Can conference (I think it was a “conference”) in Paris about the eFace product he’s been working on. It appeared on TSS today; you can find the link here. You can find more information here and here. Essentially, eFace is an implementation of XAML that runs on SWT. According to the documentation, Windows Vista, Windows XP, Mac OS and Linux are all supported.

I haven’t had a chance to look at it yet, but it looks pretty interesting.