Friday, December 18, 2009

Referencing metamodels in Xtext and using them in xpand

There are quite a few resources out there what you need to do if you want to reference a DSL in another DSL, say you need to refer from BDSL to metamodel types of ADSL.

In short you need to figure out how to configure your xtext project (add a dependency to ADSL and sort out the genmodels attribute in the xtext configutaration, more about that here) and you need to find out when to use the platform URI and classpath URI specifications to refer to the metamodels and imported models. And there is the importURI attribute which takes cares of importing your model into another model.

All that can be found in the documentation and various other resources of Xtext, however it took a good deal of time to find out how to make xpand (aka the "Generator" ) recognize your combined model. I always had all kinds of exceptions, basically stating that the xpt templates do know nothing about your referenced model, even so everything works fine in the editor.

The solution is short and simple. You just need to add a line in the MWEReader component of the workflow:

<component class="org.eclipse.xtext.MweReader">
<register class="namespace.of.BDLStandaloneSetup"/>
<register class="namespace.of.ADSLStandaloneSetup"/>

... blablabla

The line for BDSL will already be present, you just need to add the extra line. And maybe you will also need to register the generated EPackages to the StandaloneBean, as usual.

Thursday, November 19, 2009

Wordle - a toy for tag clouds

Wordle: Softwarepoets

I just had been toying around with Wordle - a website which allows you to quickly generate fairly flexible word clouds to visualize arbitrary textual content. I am currently looking into ways to visualize content (mostly based on textual models of course). There is another resource I'd like to share. A very powerful layout engine which can be used within have is prefuse, its API is very easy to understand and fairly well documented. Check out the gallery, if you'd like to know more.

Sunday, October 4, 2009

Impressions of Google wave

The other day I received my Google wave account. If you do not know what wave is: some people said that it is like email on steroids and in a way that is true, but there is more to it.

I recommend to watch the first part of the presentation held at the Google I/O conference:

The interesting concept about wave is that it rethinks how communication could be done using the internet and tries to find a solution for it. The solution might not be perfect, but so far I like it. Time will show.

The most interesting part of Google wave is that you can write robots for it, which interact with the communication. For example a robot could analyse the conversation and draw a diagramm according to the content. Writing robots is also really easy. A very good tutorial to get you started can be found here. There are APIs for java and python available. I completed the example in about 5 minutes and I am currently writing a small robot myself which will analyse a DSL to draw use case diagrams as a prototype. Apart from the robot API there are also different scenarios where and how you can extend wave.

Another nice example of the usage capabilties of the platform can be found here:

Are you using wave, have you written your own extensions? I'd be glad to hear. You can also contact me under or just leave a comment.

Friday, September 18, 2009

NetBeans RCP

During the past days I had been looking into the NetBeans RCP since I wanted to prototype a GUI rich application. I am actually amazed by it now, and wonder why I had invested the time to study the Eclipse RCP.

I think NetBeans has a couple of advantages over Eclipse when it comes to building GUI applications.

  • excellent GUI builder
  • very good module system
  • a mechanism for decoupling called lookup
  • learning curve is not very steep as you stay in the Swing idiom and do not have to learn SWT
  • good tutorials to get you started
  • a useful set of wizards
  • very good API to build explorers, editors, property sheets etc.
So far, whenever I build something which was against the NetBeans RCP idiom, it was fairly easy to refactor the code to apply what I had learned. There is also a book available in german and in english. Have a look here. I wrote a small review for it, which can be found at the end of the description, telling you what to expect.

If only Netbeans had better integration with modelling, such as Eclipse and EMF! Well, I guess we have to wait for Netbeans 23.1 M9 to see that.

Friday, August 14, 2009

Making xtext, eclipse and guice work together

There is a new entry in the xtext documentation dealing with enabling guice for your Xtext Editor.

This is pretty useful, though the same concept used to work before it only found its way into the documentation now. Hence I just wanted to share that information with you. Works really well.

name="EcoreDsl Editor">

Please not that MyLanguageName is actually the name of the factory you can find in your src folder of the UI-Project under your main package.

And now, if you'd like to write some ActionHandler for your xtext outline view, you can do just the same. Simply prefix the Handler class with the factory, and there you go!

Wednesday, August 12, 2009

Xtext 0.7.2 released, but...

I get

Cannot complete the install because one or more required items could not be found.
Software being installed: Xtext Runtime (Incubation) 0.7.2.v200908120607 ( 0.7.2.v200908120607)
Missing requirement: Xtext Generator (Incubation) 0.7.2.v200908120607 (org.eclipse.xtext.generator 0.7.2.v200908120607) requires 'bundle org.eclipse.xtend.util.stdlib 0.7.2' but it could not be found
Cannot satisfy dependency:
From: Xtext Runtime (Incubation) 0.7.2.v200908120607 ( 0.7.2.v200908120607)
To: org.eclipse.xtext.generator [0.7.2.v200908120607]

I will investigate that later.

Thursday, August 6, 2009

Setting up guice for xtext/TMF and parsing rules for validation

I am by no means a Guice expert, but here is a small code snippet which works for me, to setup TMF/xtext with guice. The main method may contain simple @Inject annotations to get your correct implementations injected.

public static void main(String[] args) {
BausteineStandaloneSetup setup = new BausteineStandaloneSetup();
Injector injector = setup.createInjector();
Main main = injector.getInstance(Main.class);

I currently use this to preparse arbitrary files which are not in my DSL and transform them. I do not want to rewrite particular checks for Rules, e.g. to verify if an ID is in the correct format, hence I just get the Parser injected and invoke the rule checking with a StringInputStream.
This looks roughly like this:

private IAntlrParser parser;
private BausteineGrammarAccess access;
InputStream inputStream = new StringInputStream("baustein " + name);
IParseResult result = parser.parse(access.getBausteinDefRule().getName(),inputStream);

There might be a more efficient way to do this, but currently I am quite happy with the solution. I guess I could try to use the lexer instead of the parser if I only want to check for terminals, but I need to extend the checks anyway.

Sunday, August 2, 2009

Lego Architecture

Available in the States: Lego Architecture
Shown in the picture is the Guggenheim Museum by Frank Llyod Wright.
Every great architect is — necessarily — a great poet. He must be a great original interpreter of his time, his day, his age.
Couldn't have said it better.

Wednesday, July 29, 2009

Architectes: tous imbéciles

A nice quote by Gustave Flaubert in his "Dictionnaire des idées reçues" (Dictionary of common ideas):
Architectes: Tous imbéciles. Oublient toujours l'escalier des maisons.(*)
(*) roughly: All idiots. Always forget the stairs of the house.

Of course there are exceptions to the rule as demonstrated by M.C. Escher, chief evangelist for cyclic dependencies.
Another very nice definition can be found in the "Devil's Dictionary" by Ambroise Bierce.

Architect, n. One who drafts a plan of your house, and plans a draft of your money.

I just realized that my architecture quotes are always slightly negative. Well, not all of them. The positive ones are usually by architects and not about architects (D'oh! I just wanted to be more positive - you may find some quotes under the musings label). So - in case you have positive quotes let me know. Just drop a note, leave a comment or draw a plan or use a fancy communication diagram @:)

UML Pinup Calendar

Christmas is around the corner, so YOU NEED THIS:
Don't forget to create your own profile and apply stereotypes to your calendar. If you are unhappy about the price tag, leave a comment. I am sure we can strike a deal so that you get a useful gift for your beloved ones (boss, colleague, wife, girlfriend...). 

Monday, July 27, 2009

Dark Factory of Mass Production

This weekend I had been on a flea market strolling about and buying books for a bargain. For my own amusement I usually drop by at the section with the kid stalls (they usually get some space for free and do not have to pay a fee). I purchased this Yu-Gi-Oh! card, which I think is a nice example of early IT education (though most of the customers will not be aware of that - yet).
I like that the factory constructs two monsters (thus emphasing the value of factories to create families of objects). I wonder if Yu-Gi-OH! also knows a Builder pattern card? I also like that the factory is called "dark". It stresses the overuse of factories in the realm of testing, where languages such as java, would very often allow us to avoid factories and use mock objects instead (though many mock object framework encourage you to use interfaces for mocking one can easily mock classes too, thus avoiding unnecessary factory code).

Thursday, July 2, 2009

Operating manual for spaceship earth

I am currently reading the book Operating manual for spaceship Earth by Buckminster Fuller. I stumpled across a quote just at the beginning which relates very much to my approach of doing consulting (in the area of systems analysis):

Wednesday, May 27, 2009

About to provide a new snapshot release for components4oaw

Good news, we are about to release a new snapshot release for the adapter to Enterprise Architect and openArchitectureWare.

Ueli is working on new features for statemachines. I do the release management (getting angry with maven as usual). I still have to work on switching to a normal eclipse update site and hope to manage the transition soon. For news on the release check here on the blog or have a look at components4oaw. I hope I will be done by this weekend and you can change to a pre-release of version 1.7.0

By the way: we are always very grateful for feature requests and bug reports.

Friday, May 15, 2009

9 reasons why offshoring projects are bound to fail

If there is an economic turn-down or crisis at the moment, it will surely do one thing: foster interest in offshoring projects for all the wrong reasons. Reason number one, being the desire to cut down software development costs. After the first wave of offshoring projects and the lessons learned by many, I think it is time to highlight again the reasons for failure in blue eyed decisions for offshoring. From 2000-2003 I had been in Bangalore, India and led a development centre for a German client. The impressions listed below are based on this subjective experience and talk to friends and IT developers I meet as a consultant for IT companies. Many of the reasons have been told before, but I have the feeling that they cannot be told to often.

1. Germans don't speaks English
Looking at the success of American and English companies with offshore projects: I wonder: - why are others successful whereas "we/Germans" fail? The first language might be a reason. Oddly enough, when I posted the article to a number of Indian friends, they all concluded that Indians are not very good in speaking or learning German. An issue I would never have thought off - nor expected. Having more than 20 languages listed as languages which enjoy official support by the India Government, Indians tend to be, by and large, wizards in mastering languages. However - I was talking about the ability of the average German to express his/her thoughts clearly and unambiguously in English. Many projects suffer from a failure in project communication. Replacing your native language with a foreign language does not help. I think it is to easy to assume, that only because English is taught in schools, we can also use it professionally at a level which is required to get the job done.

2. Implicit colonial attitude
Many project members look at their offshoring team members with the attitude of a 19th century colonial officer or missionary zealot. Or both. It is easy to find a scapegoat for project problems with that attitude. During my review process for this blog entry an Indian friend told me the following:
I would expand on this point, because it is so important but rarely understood. I agree with you on the point but my own experience with the difficulties in getting this idea across to people even in London for example, makes me feel that crucial idea must be well laid out.
Some people highlight that soft skills are a key factor in making offshoring projects a success. But soft skills are not a tool where you coach people into doing what you want to do them, they are not a tool to interpret a wobbly head shake if it is a yes or no, and neither are they a tool to amuse yourself about the Indian ability to say "understood" if according to our world nothing is clear. If anything, soft skills are the tool to question yourself what it is exactly that makes you "white" (and if you actually like that). They should address your cultural heritage directly, because many of the conflicts arise because of you.


3. All hail the waterfall model
If "we" need to do all the brain work, and them the boilerplate code, GUI frontends, the patching up - it makes sense to send a document over the ocean which contains all the analysis and design before the implementation can start. Hail the waterfall model! It does not work when you sit next door to your analysts, architects and designers - why should it work with a 1000 mile gap in between?

4. The lousy cost of living equals lousy project costs myth
Whenever I hear about off shoring projects, the main driving factor is the desire to reduce costs. Why after all are countries like India so attractive for German companies? Globalization in this context is not a market force which opens new markets for products, but opens new markets for a workforce which has a considerably smaller salary. The comparison in the costs of living is pretty fast equalled to the amount of potential savings for the projects. What is most often neglected in projection costs comparisons and success stories are the substantially increased costs in communication, travel, lawyers, standstills due to different time zones etc. Some of these problems are problems were e.g. American companies are indefinitely better than Germans. Americans are used to different time zones, have a much more multicultural society, are excelling in telephone conferences. We suck at most of these.

5. Who cares if the source code is in German?
Well everyone in your project cares. Have you ever tried to make sense out of Hindi class names? Despite of this, very often the old projects which are ready for maintenance and fixing are being offshored. Exactly those projects which have not been adapted to English as the main documentation and code language. You will have to get someone to a) understand the legacy code, the b) domain and translate the c) non-existing, outdated documentation and d) fix the spaghetti code. If you are done, you probably will already have fixed the problems yourself.

6. The "Oh, hello - who are you?" effect, also known as the good guy left the project syndrome
Personnel fluctuation was a big problem in India, I do not know how much it changed, but I cannot blame anyone for acting like a private version of Homo Economicus. After all, international companies throw around the money to lure people to their company and the next offer used to be just a step away from the freshly signed contract. On the other hand I think the model of comparing programming costs to costs of living is flawed. At least each clever programmer will easily find out, that a line of code which is easily shipped to any destination in the world is truly global and can command a price which is global. So why would anyone code for 1 Rupee if he can make a buck instead? Welcome to a flat world.

7. Mirror, mirror upon the wall, who is the fairest manager of them all?
Offshoring decisions are management decisions. Managers communicate their decisions. Managers are tempted to look good, after all their career depends on making right decisions. I tend to believe that this is the reason why we seldom hear about offshoring failures. Having lived in India I heard from the projects that were taken back. But not from the managers, but from the employees who contributed to new offshoring projects.

8. A plan is a plan is a plan
Plan to avoid the mistakes listed above. Certificates, Add more... Quote from Web: "The problem is to identify the right supplier and even then it takes a lot of work to get the ODC settled and integrated in clients processes. Certificates like CMMI, ISO or SPICE show the suppliers professional orientation, but much more has to be done do successfully integrate the ODC." etc. elaborate.

9. Put your own reason here - leave a comment if you agree or don't.

Reasons for success:

  • Patience: it took us about two years to become remotely successful, to establish best practices and procedures, to build domain knowledge.
  • Agile processes: everything was agile. If it did not work, we would change it. Every single process, every rule, every everything. We were two small companies, and could afford that (or had to endure it?).
  • On-site German speaker (on a local salary): Most of the time I was the only German speaking person within the workforce, and it helped a lot to smooth the transition.
  • Small is beautiful: we made tasks extremely small, since no amount of communication would prevent us from having misunderstandings. Working code led to realizations on both sides.
  • Dedication: My colleagues were the most dedicated bunch of people I ever worked with.
  • We did not exist to save money: Well, at least not primarily. We did exist to enable a company to increase its workforce.
  • Use the domain experts. Some time after I left the company tables turned (a little bit) and the company brought a system to the indian market which they had previously developed together with their German partner. Why is this important. It shows a true partnership and lets each partner excell in the qualities they are good at. If you outsource - outsource Research and Development, not just what you think is the boring part of software developments. Most companies I know of use the knowledge of their local partners in order to bring products to the Indian market, which are adapted to it, brought to it by people who understand the culture etc

Postscript: I had been thinking about this already for quite awhile - the current status of this entry is a draft. Not all the arguments have been polished, some are basically just ideas, but I simply wanted to go ahead.

With gratitude I would like to thank Ray Ayyar, George Kurian and Aditya Dev Sood for their helpful comments and contributions.

Thursday, May 14, 2009

Rephrase this

I tremendously enjoy taking quotes which move me and translate them to the realm of software development -  the domain in which I happen to work. The quote above had been taken from popshot, a magazine about poetry. Here is my variation (I guess it is still a bit lame):
Most developers ignore most architects because most architects ignore most developers
Got your own quote? Leave it as a comment.

Wednesday, May 13, 2009

Providing custom images for the outline view in Xtext/TMF pt 2

I recently installed the M7 build of Xtext and had to make some minor tweaks to get my code running. Doing that, I discovered a simpler way to achieve what I described in

The API either changed slightly, or it make a mistake, but the correct version now looks like this:

public class AnalysisLabelProvider extends DefaultLabelProvider {

 public String image(Actor actor) {
  String image = (actor.isSystem() ? "Node.gif" : "Actor.gif");
  return image;

 public String image(UseCase useCase) {
  return "UseCase.gif";

 public String image(Information information) {
  return "Class.gif";

 public String image(Analysis analysis) {
  return "Model.gif";

 public String image(Issue issue) {
  return "Comment.gif";

 public String image(Step step) {
  return "StructuredActivityNode.gif";

The path to the directory "/icons/ vanished. It is now a default, which can also be configured using guice. BTW, another very nice feature of the new milestone release is the new template mechanism. Read about it in the documentation, it is really easy to use.

Tuesday, May 12, 2009

Xtext M7 released

While I had been on holidays hiking in Sweden Xtext M7 was released. It is brimful of interesting new features and includes many bugfixes. Get the news here:

Saturday, April 11, 2009

Providing custom images for the outline view in Xtext/TMF

Recently I asked a question on the openArchitectureWare forum, how I can change the default image in the outline view of Xtext/TMF. Christian Dietrich was able to give me the correct hints. You can follow the discussion there, and below is a working example of the implementation of my LabelProvider. As you can see it works slightly different. The nice thing is, that due to the generated DSL classes, it is easier now to access the information from the model and static polymorphism more efficiently.

public class AnalysisLabelProvider extends DefaultLabelProvider {

public Image image(Actor actor) {
String image = (actor.isSystem() ? "/icons/Node.gif"
: "/icons/Actor.gif");
return new Image(Display.getDefault(), AnalysisLabelProvider.class

public Image image(UseCase useCase) {

return new Image(Display.getDefault(), AnalysisLabelProvider.class

public Image image(Information information) {
return new Image(Display.getDefault(), AnalysisLabelProvider.class

public Image image(Analysis analysis) {
return new Image(Display.getDefault(), AnalysisLabelProvider.class

public Image image(Issue issue) {
return new Image(Display.getDefault(), AnalysisLabelProvider.class

public Image image(Step step) {
return new Image(Display.getDefault(), AnalysisLabelProvider.class

That's it. The rest can be seen from the discussion. Link provided above. Oh, one more thing: you need to add the icons folder to your plugin resources! The implementation could also be made more efficient (prevent loading of images again and again).

Thursday, April 9, 2009

ODA Ecore and EMF Query

By accident I already published this article before actually writing this, so it appears in the news feed. Hence the briefest of brief contents:

At (written by Tim Myer) you will find a very nice description on how to use Ecore Modells as an ODA Datasource, and connect the result to BIRT. I just tested it again using BIRT 2.50 and Eclipse 3.5. Worked like a charm.

I will write more about EMF Queries when I find the time.

Tuesday, April 7, 2009

Wittgensteins take on languages

Having spend half of my life learning UML and with a keen interest in designing domain specific languages, I had to smile when I came accross this quote. Makes for a nice thought. In which language do you guess, you get lost first? How do we design a language so that we do not get lost. Or to quip: "Worüber man nicht sprechen kann, darüber soll man schweigen."
[rough translation into English: "Language is a maze of different paths. You come from one location and you know your way around; you come from another path to the same location, and you don't find your way."]

Monday, April 6, 2009

EMF Reference Card

A very nice reference card about EMF is available from It has been written by Ed Merks and James Sugrue, so that you can trust the information inside.

The reference cards by dzone are usually covering a wide range of topics. I find them quite valuable for exactly the kind of purpose they were designed for: give a reference.

Saturday, April 4, 2009


In a recent blog article by Adam Bien, he pointed out that a perfect architecture is one, where there is nothing left for deletion. I agree. Ever in search to look at things at a different perspective, I recently started reading quite a few things about "real" architects and designers, thus not software related, but building related. It is amazing how many of the problems are totally similiar. Hence I'd like to share my favorite quote with you.

Thursday, April 2, 2009

openArchitectureWare and Enterprise Architect UML

Today we released a new version of the Enterprise Architect adapter to the Eclipse UML2 model. With that and additional helper classes, such as a workflow component, it is possible to use Enterprise Architect and openArchitectureWare.

I will post a small tutorial blog entry soon, demonstrating the use of the tool support. The maven artifacts and direct downloads can be found at: A release description here: An eclipse update site is on the todo list. Actually as the person resonsible to do the releases, I had higher expectations when I decided to use maven, but with multiproject builds it is a plain nightmare to do releases.I will keep it probably to get the reporting and website updated, for which it is reasonably useable.

Wednesday, April 1, 2009

Unit tests to check against cyclic dependencies

Some sample code to write a unit test which checks the project for cyclic dependencies. It is using a paramerized Test class, where each package is passed to the constructor of the test object. It uses jdepend  to  analyse the project based on the compiled class files located in the directory 'target/classes'.

public class JDependTest {

     private static JDepend jdepend = null;
     private static Collection packages = null;
     private JavaPackage pack1 = null;

     public static Collection data() throws IOException {
         Collection result = new ArrayList();
        jdepend = new JDepend();
        packages = jdepend.analyze();
        for (Object p : packages) {
            result.add(new Object[]{p});
        return result;
    public JDependTest(JavaPackage pack) {
        pack1 = pack;
    public void cycleTest() {
        assertFalse(pack1.getName() + " failed", pack1.containsCycle());

This is the output in Netbeans. It could be improved by adding the cycles which have been detected, but that can also be seen in the jdepend report.

Tuesday, March 31, 2009

Using the EditingDomain to modify Ecore models

EditingDomain editingDomain = AdapterFactoryEditingDomain.getEditingDomainFor(eClass);
Command cmd = AddCommand.create(editingDomain, eClass, null, eOper);


The above code snippet shows an improvement over the modifications done to the Ecore model in the posting about creating new actions for the Ecore Editor. The previous version had the drawback, that the changes to the model couldn't be undone. That is going to change now forever, just by exploiting the EditingDomain which is provided by EMF.

In order for this code to run, you will need to add org.eclipse.emf.ecore.edit to your list of plugin dependencies. I will continue to post some examples and make the editor available on Keep listening for more information.

Monday, March 30, 2009

Using Xtext in standalone mode

public static void main(String[] args) {
ResourceSet resourceSet = new ResourceSetImpl();
URI uri = URI.createFileURI("src/test/test.mydsl");
Resource resource = resourceSet.getResource(uri, true);
Model model = (Model) resource.getContents().get(0);
for (org.xtext.example.myDsl.Class clazz : model.getElements()) {

Today we look at using the new TMF Xtext Framework which is currently available as beta version in standalone mode.  Things got considerably easier since the current version. The example has been built using Eclipse 3.5M6. The DSL is the one which is generated after creating a sample Xtext project. TMF Xtext will be available from June onwards.

Looking at the code snippet above they only thing which is worth mentioning is the class MyDslStandaloneSetup which is generated as part of your Domain Specific Language. It does all the required setup work. Xtext is using guice for its dependency management and configuration, but we do not not need to worry about that. The static doSetup method is doing all the work.

After initialising we can simply create a resource. All the required factories have already been registered using the StandaloneSetup class. Because Xtext is now also using generated classes which are derived from the ecore model, querying the model is even easier than before. No more dynamic EMF is required! The Model and Class classes are examples for the generated classes.
Questions? Post a comment!

Sunday, March 29, 2009

Creating useful actions for the EMF Ecore Editor

When using the Ecore editor to produce models which can be used to generate code, it is often a tedious task to create some of the required artefacts.
Such as:
  • create an operation with ready made annotation for inclusion of an operation body in the generated code
  • create a validator constraint operation
  • create a derived, volatile attribute
  • ...
Create a new plugin project, e.g. org.softwarepoets.emf.ecore.editor.extensions

Open the manifest and add this to your plugin.xml file:
<objectContribution id="org.eclipse.emf.ecore.editor.CreateEOperationWithAnnotation"
<action id="org.eclipse.emf.ecore.editor.CreateEOperationWithAnnotation"
label="Codegen Operation"
menubarPath="additions" class="org.softwarepoets.emf.ecore.editor.extensions.CreateEOperationWithAnnotation"

In the dependencies section of the manifest add org.eclipse.emf.ecore.

Create a new class org.softwarepoets.emf.ecore.editor.extensions.CreateEOperationWithAnnotation:

public class CreateEOperationWithAnnotation extends ActionDelegate implements
IActionDelegate {

protected EClass eClass;

public CreateEOperationWithAnnotation() {

The run method:

public void run(IAction action) {
InputDialog dialog = new InputDialog(PlatformUI.getWorkbench()
.getActiveWorkbenchWindow().getShell(), "Enter Operation name",
"Enter the name of the operation without parameters using valid java naming conventions.", "", new JavaNamingValidator() );

if ( == InputDialog.OK ) {
String name = dialog.getValue();
EOperation eOper = EcoreFactory.eINSTANCE.createEOperation();
EAnnotation eAnnotation = EcoreFactory.eINSTANCE.createEAnnotation();

The implementation of the run method will also display a small dialog in order to ask the user for the operation name.

How to decide on which class the operation should be added and if the action should be enabled:
public void selectionChanged(IAction action, ISelection selection) {
if (selection instanceof IStructuredSelection) {
Object object = ((IStructuredSelection) selection)
if (object instanceof EClass) {
eClass = (EClass) object;

eClass = null;

The validator class, to validate the input of the user (draft version, can be improved a lot):
class JavaNamingValidator implements IInputValidator {
public String isValid(String newText) {
if (newText == null || newText.length() == 0)
return "You must enter an operation name.";
// maybe include an elaborate regular expression here...
// otherwise ok
return null;

After you are done, you can start a new runtime workspace, create an Ecore model, select an EClass and right click. You should see the additional action in the popup menu. After completing the dialog you should see something like this:

Friday, March 27, 2009

Happy Birthday Futurist Manifesto

Filippo Tommaso Emilio Marinetti of italien origin, born in Egypt and died in Italy, wrote the first version of his famous Futurist Manifesto on February, 20th 1909. Brimful of hatred against the established academic art world and full of anger, it created a turbulent view on a world, which adored machines, speed and rejected any kind of tradition.

Literature has up to now magnified pensive immobility, ecstasy and slumber. We want to exalt movements of aggression, feverish sleeplessness, the double march, the perilous leap, the slap and the blow with the fist.
We declare that the splendour of the world has been enriched by a new beauty: the beauty of speed. A racing automobile with its bonnet adorned with great tubes like serpents with explosive breath ... a roaring motor car which seems to run on machine-gun fire, is more beautiful than the Victory of Samothrace.
Whether the later links to facism in Italy were inevitable due to their special philosophy or not, should not be discussed here. Rather by joining the birthday celebrations we'd like to highlight the existence of the Manifesto of the Futurist Programmers whose programme we share beyond doubt. Written in 1991 it is equally important as a document which point sus to believing into fast software, good software, working software as opposed to modular, reusable and designed software.

1. To destroy the cult of the past, the obsession with all things old, academic pedantry, and formalism
2. To cast our scorn profoundly on every last form of imitation
3. To exalt every form of originality, even if foolhardy, even if extremely violent
4. To bear bravely and proudly the smear of "madness" with which they try to gag all innovators
5. To look on the lot of computer "scientists" as at one and the same time useless and dangerous
6. To rebel against the tyranny of the words "extensible" and "reusable" expressions so elastic that they can just as easily be used to demolish the art of Atkinson, Baumgart and Deutsch as well
7. To sweep out of the mental field of programming all themes and subjects already exploited
8. To render and magnify the life of today, incessantly and tumultuously transformed by science triumphant
Without the Futurist Manifesto, no Manifesto of the futurist programmers. Throw your documentation in the bin, pump up the volume of your MP3 player and start celebrating! Happy Birthday! Leave a comment if you couldn't agree more.