The Visual Editor blog

EMF-Prevayler, or PreMF

djo — 2011-11-28T23:04:27-04:00

Have you ever wanted 100% transparent persistence for your memory-based EMF models?

As-in, after issuing one line to connect a Resource to a directory in your file system, you don't have to think about persistence any longer; you just manipulate your model using regular EMF and Java code. And all changes are automatically persisted to disk.

If so, maybe you would like something like the following:

// Given the following helper method:
 
private Resource makePersistentSystem(String tempDirPath) {
	Resource newSystem = new XMIResourceImpl();
	EmfPersister persister = new EmfPersister(newSystem, tempDirPath, -1);
	Resource persistentSystem = persister.getPersistentSystemRoot();  // Get the persistent decorator
	return persistentSystem;
}
 
// We can write:
 
String tempDirPath = tempDir().getAbsolutePath();
 
// Create a Resource and make it persistent
Resource persistentSystem = makePersistentSystem(tempDirPath);
 
// Add a Person to the persistent resource
Person person = factory.createPerson();
person.setFirstName("Dave");
persistentSystem.getContents().add(person);
 
// Create a second (empty) Resource
Resource secondSystem = new XMIResourceImpl();
 
// Attach it to the persistent system's directory, which will restore the 
// first system's contents into the second one
new EmfPersister(secondSystem, tempDirPath, -1);
 
// Now the second system should have a *copy* of the Person above
assertEquals(1, secondSystem.getContents().size());
Person restoredPerson = (Person) secondSystem.getContents().get(0);
assertTrue("Structurally equal", EcoreUtil.equals(person, restoredPerson));
assertFalse("Not the same object", restoredPerson.equals(person));

What's happening here is that whenever an object inside the Resource is mutated, Prevayler transparently notes this fact in a transaction journal in the specified directory. You don't have to do anything to make it happen.

The current implementation puts a decorator around every EMF object that intercepts method calls and if they mutate state, runs them through Prevayler.

So far there are only two catches.

1) When you create a new object, after adding it to a PreMF-managed object graph, you have to remember to either manually call the API that makes the object reference itself persistent, or just get it back out of the object graph (which will give you a persistent version).

2) #equals behaves slightly differently with persistent and non-persistent objects. If you ask a persistent object if it is equal to a non-persistent object, it will do the right thing. But a non-persistent object won't know how to compare itself with a persistent object. This only matters if you forget to make a new object reference persistent after adding it to the persistent object graph (as described in #1).

The current experimental implementation just makes the contents of XMLResource#getContents() persistent. Work is underway to make the rest of the EMF API persistent the same way.

Does this sound interesting/exciting?

I'm still an EMF newbie. Details of the approach/design are in the README.md on GitHub:

https://github.com/pieceoftheloaf/emf-prevayler

I'd love to hear what people think of this and/or if there's a better way to accomplish the same thing.

Read or add comments to this article

Eclipse 10 year Retrospective and Challenge

djo — 2011-10-06T13:30:11-04:00

On his blog, Ian Skerrett invites people to comment on when/how they joined Eclipse. As I responded, I found I was sort of writing an Agile Retrospective. Since those thoughts felt like they might be valuable on a larger scale, I am repeating them here.

I became a member of the Eclipse Consortium during the year that we were creating the Foundation. I will never forget the Consortium’s last meeting held at the American Airlines conference facility in Dallas where the mood was festive because we had done what we set out to do–we had created the Eclipse Foundation and we were officially handing the keys to Eclipse over to them.

My official job was to represent a small software development company that made a good living adding value to IBM’s iSeries tooling built on top of Eclipse. Unofficially, I became a voice for many small companies and especially for the community of open source developers.

This led to interesting opportunities: One was the opportunity to negotiate on a conference call with the big company lawyers about how the patent retaliation clause in the EPL would work out in practice for software developers. Many software developers have a very negative view of corporate lawyers, but these were clearly on our side, had a clue, and were a joy to work with. On the other hand, I had a very engaging conversation with Richard Stallman about the relationship between Free Software and Open Source (and Eclipse in particular) when the Free Software community urged us to make the EPL compatible with the GPL.

(Over the years, Eclipse has truly attracted some of the best of the best minds I have ever worked with.)

In the end, the EPL and GPL have managed to coexist inside Linux distributions, and I personally appreciate both the passion of the hard-core Linux community and the powerful pragmatism the Eclipse community had when it created a truly symbiotic relationship between big corporations and open-source.

In my own view, it is this powerful pragmatism combined with open-source symbiotic coopetition that has made, and continues to make the Eclipse community great.

Looking forward, I believe that the biggest challenge Eclipse (and, indeed all of Java) faces is that we are hitting the complexity wall of what can be done with the Java language. OSGi goes a long way toward helping on one front. EMF helps a lot on another.

The challenge I would put before the community today is to embrace and incorporate the emerging agile/functional languages like Scala, Groovy, JRuby fully into the Eclipse, Modeling, and OSGi ecosystems.

This will continue to ensure that the small developer with the New, Cool idea has a powerful enough lever that we will continue to see awesome ideas like Mylyn and many of the EMF ideas sprout, take hold, and grow up within the Eclipse ecosystem.

Read or add comments to this article

A seamless installer/updater for P2 applications

djo — 2011-10-06T13:25:26-04:00

As promised, I've updated the P2 updater/installer example that Patrick Paulin and I presented at EclipseCon to demonstrate how to use this code in a production manner.

Here's the original EclipseCon session announcement. And the original EclipseCon presentation and code examples we used back at the conference.

Enjoy!

Read or add comments to this article

The OSGi Building Block Pattern: An Invitation

djo — 2011-03-14T23:15:45-04:00

Have you ever wondered why it seems so hard to come up the OSGi or RCP learning curve? Or, if you're already an OSGi expert, why beginners seem to have so much trouble “getting it”?

I believe one reason is that there is an impedance mismatch between the way OSGi applications are built and the way the Eclipse IDE works. More importantly, I believe that understanding this impedance mismatch illuminates a very fundamental architectural pattern in OSGi development that I call the OSGi Building Block pattern.

In this blog article, I will discuss the OSGi Building Block pattern in the abstract.

Next week at EclipseCon, Patrick Paulin and I will deliver real code showing how to leverage this pattern to make Eclipse RCP and server-side OSGi application development much easier (Architecture Patterns and Code Templates for Enterprise RCP Applications).

What is the OSGi/Eclipse Impedance Mismatch?

Consider this thought:

Eclipse works in terms of projects and dependencies. But no single project can fully define a production-quality OSGi application.

Why?

Let's use Eclipse RCP as an example:

An RCP developer might first use the “RCP Application with a View” wizard to create her initial RCP application. This wizard generates a single project defining a single OSGi Bundle.

Then the average beginner clicks the “Run” button to launch the platform and to see the wizard's result.

But in order to deploy the application, an RCP developer must create at least the following extra artifact(s):

A Product configuration

and normally for an enterprise-class project:

A Feature definition (for her bundle)
A releng project to drive either Maven/Tycho or PDEBuild.

And there is nowhere that I am aware that documents all of these steps in one place. So a beginning RCP developer may flounder for months before he realizes what the minimal ingredients are in a production-ready Eclipse RCP application.

What are the minimal OSGi/RCP ingredients?

For a Feature-based RCP product, the minimal building-block for a production-quality application can be represented by the following quad:

(Bundle+, Feature+, Product, Releng)

[The trailing plus sign signifies “one or more”, just like in a grammar.]

In other words, for production purposes, the *minimal* RCP application is:

One or more Bundles
Contained in one or more Features
In a Product configuration
Built by some sort of release engineering project (e.g.: Maven/Tycho or PDEBuild)

But Eclipse provides no wizards to create all of these things at once. Eclipse provides no refactorings to keep all of these things in sync as they change over time.

The Eclipse RCP wizard and the Eclipse IDE want us to think in projects. But OSGi wants us to think in terms of deployable bundles. Eclipse requires the OSGi (RCP, server-side) developer to keep this entire model in his head, and to manage it manually.

(I think I mentioned that we will deliver simple code illustrating all of this next week? )

What about other OSGi uses?

Wait! There's more!

The same principle applies for server-side OSGi, just with different names for the parts! For example, Virgo has the following minimal building-block:

(Bundle+, Plan+, ContainerConfig, Releng)

(Okay, I know you can deploy bundles to a WAR, but my understanding is that Plan files are the “new and approved” way to work with Virgo.)

And an OSGi bundle, deployed via P2 is the following minimal set of things:

(Bundle+, Feature+, P2RepoProject, Releng)

Viewing OSGi this way has helped me think about RCP applications much more clearly, because the number of distinct concepts I have to keep track of suddenly just went to 4.

It has also helped me understand how to design my builds in a modular way, because as Nick Boldt blogged, a build's target platform can be composed of multiple P2 repositories, which can be the result of prior builds. In other words, my build can consume its own output.

General form of the OSGi Building Block Pattern

I call this OSGi quad the “OSGi Building Block” pattern because it comes up frequently in one form or another in nearly all flavors of OSGi software development. The general form can be described as:

(Bundle+, Packaging+, Deployment, Release engineering)

I believe there are two powerful ramifications to this:

Having standard names for things helps us to talk and reason about them. Understanding the OSGi Building Block pattern is the key to making OSGi (in all its forms) simple and easy.
Direct tool support for the OSGi Building Block pattern: Maven archetypes, IDE wizards, and IDE refactorings would all be beneficial. Ultimately, these things will help to drive OSGi's TCO down and drive OSGi as an enterprise standard.

Invitation to the community

Following this second point, I would like to issue the following challenge and invitation to the OSGi community:

When things represent the same idea, let's try to standardize the terms we use to describe them. For example, I propose that we use the term “Packaging” to describe the singular concept represented by both a Plan and a Feature. But as the experts, does that make sense to you?
Since developers deal with OSGi applications in terms of repeating instances of this minimal quad, let's give them IDE tooling to let them deal with each instance of this quad as a discrete unit.

Invitation to BoF

To facilitate these discussions, I would like to invite all of the OSGi stakeholders to a BoF session this coming week at EclipseCon.

I think that OSGi's future is bright, and I think that by driving concrete plans to improve developers' lives using the OSGi Building Block pattern, we can help.

(And one final plug for Patrick and my session next week:)

If you're wondering why and how this makes OSGi development simple, come to our tutorial next week at EclipseCon: Architecture Patterns and Code Templates for Enterprise RCP Applications. Next week Patrick Paulin and I will make all of these abstract ideas concrete with real code you can take with you and use as the basis for your next project.

Read or add comments to this article

New XScalaWT feature- Assign to properties

djo — 2011-02-11T22:06:39-04:00

In XScalaWT, to set a layout, you previously would write (same as Java):

setLayout(new FillLayout())

Now, you can write:

layout = new FillLayout()

Most SWT properties now work this way. So for example instead of using setters everywhere you can now write code like:

progressBar(
   minimum = 0,
   maximum = 50,
   selection = 20
)

Which is much cleaner and easier to follow.

Thanks much to Jean-Philippe Pellet for the idea and implementation of this feature!

XScalawt can be found on GitHub at: https://github.com/pieceoftheloaf/XScalaWT/tree/gh-pages

Read or add comments to this article