Java Blog

Marcel Gorri (Motorola)

Freescale Semiconductor, announced the launch of its CodeWarrior 10 development suites, based on open-source Eclipse technology for helping streamline embedded software development.

The Keil Development Studio 5 (DS-5) Application Edition features an Eclipse-based project manager for multiple usage as well as C/C++ and assembler code editing functions.

Adobe Ajax Android Anwendung Apache API C++ Community Developer Eclipse Eclipse Foundation Embedded English Enterprise Entwickler Equinox Galileo Google Handy IBM IDE Individual Java Member Microsoft Mobile Modeling NetBeans News Open …

Intel übernimmt den Hersteller des Software-Emulators Simics, der vor allem bei der Software-Entwicklung für Embedded-Systeme eingesetzt wird. Für den Vertrieb sorgt ab sofort die Intel-Tochter Wind River.

I’m continuing on my ancient quest for Graphviz DOT support in Eclipse: after implementing initial support for rendering DOT with Zest in Eclipse through dot4zest and some early tinkering with dynamically drawing DOT embedded in wiki markup with Zest, I have now started to approach the next step: integrating the Graphviz export into the Mylyn WikiText editor.

Say we are editing embedded DOT in wiki markup with the Mylyn WikiText editor and have an open dot4zest Zest graph view, which displays a Zest representation of the DOT graph (powered by the EMF model visualizer and Xtext – vote Xtext!):

Now upon saving, dot4zest asks if we want to add a reference to the Graphviz image export to our wiki markup file (requires a local Graphviz installation, for which we are prompted the first time the export happens):

If we say yes, dot4zest puts a reference to the exported image file into our plain text wiki markup file. This adds an image representation of the Zest graph displayed in the view to output generated from the plain text – like HTML export or the preview tab of the Mylyn WikiText editor:

Being sort of pre-incubation, this is all still fairly restricted and experimental, e.g. it currently supports only a single graph per file and only Textile markup. I’ve added these latest changes to the update site, so if you want to check it out update your existing dot4zest installation or install it from the update site at http://quui.de/updates (category Zest -> feature dot4zest).

I recently rewatched “How to Design Good APIs and Why it Matters” (youtube video embedded below).

There are many lessons that can be learned from designing a good api, one of the tips is to make sure that your method names make sense. I ran across some code today in a test case, named:

createStuff

Great, I used to write these types of method names when I was starting out. Figuring they were throw away, or just funny. However, over the years I tend to avoid these names. Why, because 6 months later I’m trying to remember what type of stuff is being created. The same thing goes with naming variables:

that

While it is cute, especially when you are comparing this to that, it can be harder to figure out 6 months later what that really entails depending on the code. Choosing proper names does help with the overall maintainability of the code. A computer may not care, but a human has to know quickly what is going on.

Another favourite I’ve seen lately is naming a variable soup. What is soup? What does it contain? Is it vegetable, egg drop, beef, or chicken noodle? Descriptive variables help yourself and those that have to maintain the code after you leave.

If you are not using a static analysis tool to help detect possible bugs ahead of time, why not? If you are looking for a way to help contribute to an open source project, but are not sure where to start, consider running FindBugs or PMD against that code base. Submit some patches to the committers. It is amazing the type of Homer Simpson “DOH!” moments these tools find.

An example:

  if (someNullClass == null) {    _log.info("Error getting class name" + someNullClass.getName());  }

Obviously if this code ever was hit, it would toss a NullPointerException. However, I found similar code that had been in place for 3 years.

Your build system can help you out with reporting these types of issues. Hudson has the ability to display both FindBugs and PMD reports. These types of tools can really help clean up your existing code, and help to catch bugs before they can happen. I’ve also seen them help increase performance on some code bases. A very common pattern I keep seeing is string concatination in Loops. This is particularly nasty depending on the number of iterations, and is an easy thing to fix, by making sure you use StringBuilder or StringBuffer instead.

Here is a suggestion. Since for those that are on the Helios release train, M7 is supposed to be for bug fixes and documentation. Why not take a part of that time to run FindBugs or PMD against your code, and try to address as many of these bugs as possible. If you haven’t run these tools against your code base, you might be surprised what they find.

A constant gripe I hear from committers is that there is not enough resources to fix all the bugs, but how about we try to prevent some from ocurring in the first place. Then you can have more time to work on your features and that killer E4 application.

I am currently working on a small Plug-In that some of you might find useful (especially if you are hanging out in IRC a lot). The plugin allows you to select resources, classes or methods in Java projects and posts them to your favorite pastebin. After that it provides the URL of the pastebin entry in your clipboard so you can easily send it to others.

This little video demonstrates this:

Some pastebins allow the user to specify additional options when posting. This will be covered when the user helds down the “CTRL” while selecting the menu entry. A dialog is then display where the user can adjust such options. Likewise he could change the content type of the pasted text, if the automatic detection failed.

The Plug-In will be released under EPL 1.0 and the source will be up at github.

Now, if anyone of you have a nicer name for the Plug-In, I would like to replace the rather generic “CopyTo” (Pasty?).

The Plug-In is very easily extensible with new pastebin providers. In fact all current providers are supplied via Fragement-Bundles that basically just add their menuContribution the the CopyTo menu.

There is support for the usual redirect based pastebins, as well as ones that send back JSON. Additional response handlers can be easily plugged in (SOAP *yikes*) and additional JSON helpers, that extract the new location URL component from a JSON response are queried using the Eclipse IAdapterManager.

Currently there is only support for copying JDT elements (Classes, Methods) but other sources of “Copyable” content can be also plugged in via Adapters.

I also plan to provide a “History” view of pastes that allows you to copy the URL again into the clipboard at any time.

Unfortunately I have family that uses Lotus Notes and because they know I work for Lotus they think I am their personal technical support.  Specifically my cousin has been complaining about this feature for years so I wanted to see who else thinks this would be a good idea.  The behavior is, once you do a spell check, save the email as draft and go back to that email later you should not have to re-check the words you already have signed off on.

Note: There is a poll embedded within this post, please visit the site to participate in this post’s poll.

technorati tags: lotus notes, spellcheck

Time flies, it is more than 3 years ago that Bjorn Freeman-Benson, BJ Hargrave, and me sat down after the 2006 conference to discuss the possibilities to organize an OSGi DevCon in conjunction with EclipseCon. Today I am proud to announce the 4th OSGi DevCon in Santa Clara, March 22-25. The program is, as usual, staggering. It always impresses me how many people are willing to contribute to EclipseCon/OSGi DevCon. Overall there were more than 350 submissions and about 60 of those were for OSGi DevCon. Picking the most interesting program was even harder than previous years because there is less space; we therefore have less time for OSGi DevCon. However, the resulting program is probably of even higher quality.

First I would like to draw your attention to the fact that we will officially publish the OSGi Enterprise Specification during EclipseCon. The OSGi Alliance will host a BOF on Monday night. One of the co-chairs of the OSGi Enterprise Expert Group, Tim Diekmann, will give a presentation during this BOF of what is in this specification and why it is ground breaking.

We have three tutorials. The first tutorial is from the people that wrote the OSGi and Equinox: Creating Highly Modular Java Systems book. You will get a feel for Toast telematics! See Working with OSGi: The stuff you need to know.

The next tutorial is from Kirk Knoernschild and Neil Bartlett, both very experienced developers and excellent writers and presenters. This tutorial was actually chosen in the EclipseCon Program Commitee top 5. The subject is a very hot topic at the moment: modularity. We all learned the lessons about coupling and cohesion. However, applying those lessons in large developments is still hard. This tutorial will give you theoretical as well as practical insight in modularity and using OSGi to achieve it. See Modular Architecture from Top to Bottom.

The last tutorial is from Karl Pauls and Marcel Offermans. They are the lead developers of the Apache ACE project and have been developing with OSGi forever. Their subject is absolutely core for OSGi although not always that visible. OSGi is not a “Hello World” technology, such examples only work well when the scope is small. The scope of OSGi is, however, large scale technology. Size does matter for OSGi. A consequence of the scale is that systems have a large number of bundles. This number becomes so large that handling these bundles requires automation because it is just too much to do by hand. Karl and Marcel will teach how to manage installations that reach these problems. See Become a Certified Bundle Manager today.

The first long talk is a must for anyone using OSGi. One of the most exciting pieces of work inside the OSGi is the nested framework RFC. Nested frameworks bring back the initial philosophy of OSGi: the bundles are your application. Enterprise servers based on OSGi starting to deploy many applications inside a single framework. In such a constellation, your peer bundles and peer services might no longer be yours. Nested frameworks returns to this model, an application will be installed in a child framework, also called composite bundles. The lead developers of Eclipse Equinox as well as Apache Felix will present the proposed architecture and discuss merits, pitfalls, and problems that still need to be solved. So do not miss Composite Bundles – Isolating Applications in a Collaborative OSGi World.

OSGi is like a sharp knife. When used well, it is extremely useful, when used wrongly it hurts. Chris Aniszczyk, Jeff McAffer, Martin Lippert, and Paul Vanderlei have been working with OSGi for the better part of the noughties and therefore have lots of experiences and the bruises and cuts to prove it. Between them they cover almost any computing aspect that can be used in conjunction with OSGi. Jeff was the driver behind Eclipse’s adoption of OSGi, Chris is the lead developer of PDE, Martin has worked on Aspect Oriented Programming in Eclipse including the weaving issues and is an aficionado of OSGi as well, and Paul brings the experience from the embedded world. A must for anybody that wants to adopt OSGi. See OSGi Best and Worst Practices.

OSGi is at the foundation of RCP, obviously. However, you can use RCP and not see much of OSGi. David Orme has been contracting for J.P. Morgan where they created an internal platform based on RCP. In the last few years they re-architected this platform to take more advantage of OSGi. This is a very good experience report for anybody that has to develop software to be used inside large organizations. See OneBench Reloaded – Pushing the (OSGI) Modularity Story in an Enterprise-wide Rich Client Stack.

Looking at the size of this blog, I do not think I should loose more readers going through each of the 25 mins talks, even though I think they’re more than worth it. I therefore list them here as bullets:

• Apache Aries: Enterprise OSGi in Action – A report from a new open source project that will bring us lots of enterprise components for OSGi. Graham Charters from IBM will present.
• My Unmanned System is Eclipse Powered – Next time you see an unmanned vehicle, OSGi might be behind the wheel. Talk about cool OSGi apps! Tankut Koray will show you the role OSGi plays in their architecture.
• Next Generation OSGi Shells – Traditionally shells run inside the OSGi framework, however, this shell works as launching tool, interacting with a Paremus’ Nimble to find the necessary bundles. Robert Dunne will tell you about these shells and show you how easy it is to deploy applications consisting of many bundles.
• OSamI Tools for OSGi Application Developers – OSamI is a very large cross-european project to develop common technology for ambient intelligence, all based on OSGi. Naci Dai and Murat Yener from eteration A.S. will tell you more.
• Managing OBR Repositories with Nexus – Maven is moving to OSGi and there is more and more collaboration. Sonatype has adopted OBR in their Nexus repository, allowing it to play with the advanced resolvers that appearing in the market. Jason van Zyl, the man behind Maven, will tell you about their strategy.
• Using JPA in OSGi – Mike Keith and Timothy Ward are the lead authors of the OSGi JPA adaption, a part of the OSGi Enterprise Specification. See how you can simplify using persistence in OSGi bundles.
• OSGi Enterprise for Java EE Developers – How do you go from Java EE to OSGi? Many patterns that are necessary in Java EE do not work well in a very modular environment. Timothy DeBoer will show you how to use Eclipse tools to ease the transition.
• OSGi & Java EE in GlassFish – When Glassfish adopted OSGi a few years ago I was very excited to see how Java EE and OSGi can co-exist, each providing their strengths. Since then, the Glassfish team has more and more adopted OSGi, they even hired Richard Hall, the lead Apache Felix developer. Sahoo and Jerome Donchez are the lead architects and will report to you about the new cool features.
• Realistic Remote Management of OSGi-based Residential Boxes – OSGi was made to be managed remotely. However, managing thousands of devices running OSGi somewhere out there remains a complex area. Dimiar Valtchev from ProSyst has a very long experience with this problem and will elucidate you on the issues and solutions.
• Overcoming sticker shock: addressing the unexpected costs of moving to OSGi in the enterprise – Eric Johnson from TIBCO will explain you what you can expect when you move from a Java EE environment to OSGi, the rules and patterns that work are quite different. This will be an experience report but will also focus on how the community can work to ease this migration.
• Making Dependency Injection work for you – Joep Rottinghuis and Parag Raval from eBay tell you how to use Spring DM to use Dependency Injection in bundles.
• Logging in OSGi Enterprise Application – As a non-enterprise programmer I am always in awe when I see the avalanche of logging information coming out of enterprise programs. However, it seems important and OSGi puts some unique challenges in the way of traditional loggers because they often require global visibility and of course the OSGi Log Service. Ekkehard Gentz provides an overview and a demo of OSGi logging.
• ScalaModules: OSGi the Easy Way with a Scala DSL – The last months I’ve tried to use Scala because it has features I know from my Smalltalk days and daily miss when using Java. Though any new programing language is painfull to learn (what takes you seconds in Java initially takes you minutes in Scala because you have to figure out how), Scala really looks very interesting. Roman Roelofsen and Neil Bartlett will report to you about Scala Modules, a way to bring modularity to the Scala Language.

On Valentine’s day the early registration price will end and you’ll have to pay the full amount. So be sure to register as soon as possible to take advantage of this discount. If you’re an OSGi member, you can get an additional discount if you register here with the email address you use on the OSGi members web site.

I am looking forward to see you again in this 4th OSGi DevCon, lets hope it will be the best ever!

Peter Kriens

As Jens mentioned in his recent blog post, parts of the Draw3D renderer have been rewritten in the past weeks. The initial motivation was to improve the visual rendering quality of 2D content (embedded GEF editors) and text, but during development it turned out that a lot of optimization would be necessary to keep the performance at acceptable levels. Eventually, I rewrote the renderer to take advantage of some advanced OpenGL features and now the performance is a lot better than it ever was.

In this blog post I will briefly explain how the 2D rendering system was redesigned over the course of GEF3D’s existence and how it was possible to achieve both a gain in the visual quality and the rendering performance at the same time.

First, let me introduce the initial 2D rendering system that Jens designed before I came on board. GEF uses an instance of the abstract class Graphics to draw all figures. Actually, figures draw themselves using their paint method whose only parameter is an instance of Graphics (this is defined in the IFigure interface). The Graphics class provides a lot of methods to draw graphical primitives like lines, rectangles, polygons and so forth, as well as methods to manage the state of a graphics object. Usually, GEF passes an instance of SWTGraphics to the root of the figure subtree that needs redrawing. SWTGraphics uses a graphics context to draw graphical primitives, and the graphics context usually draws directly onto some graphics resource like an image or a canvas.

So what Jens did when he wanted to allow 2D content in GEF3D was that he simply passed an instance of SWTGraphics to the 2D figures that rendered into an image in memory. This image was then transferred to the graphics card and used as a texture. This system was very simple and required hardly any additional coding at all. The problem with this approach however is that whenever the 2D content needed redrawing (after some model change for example), the entire image had to be redrawn and uploaded to the graphics card again, which is a very costly process. First, the image has to be converted into a ByteBuffer and that buffer must then be uploaded from system to video memory through the bus. For normal-sized image, this can take up to 500ms.

To alleviate this problem, I wrote another Graphics subclass that uses OpenGL to render the 2D primitives directly into a texture image in video memory. This eliminates the uploading step and thus improved performance considerably, especially the delay after any model change when the texture image had to be uploaded into video memory. But it did not help with the second major problem: It still used textures. The problem with using textures to display 2D content in 3D is that while the texture image may look sharp and very good by itself, it gets blurry and distorted when it is projected into 3D space due to all the filtering that has to take place. Especially images that contain text become very hard to read in this approach, as you can see in this screenshot:

Another approach to rendering 2D content in 3D is not to use textures at all, but to render all 2D primitives directly into 3D space in every frame (so far, only the texture had to be redrawn only after a model change occurred). This eliminates all problems related to texture filtering and blurring once and for all. Combined with vector fonts (to be described in another blog post), direct rendering results in the best possible visual quality. The problem is that everything needs to be rendered in every frame all the time. I quickly discovered that simply sending all geometry data to OpenGL in every frame (this is also called OpenGL immediate mode) would kill performance – even in small diagrams, navigation became sluggish.

Essentially, the FPS in GEF3D are limited not by the triangle throughput of the video card (how many triangles can be rendered per second?), but by the bus speed (how much data can we send to the video card in a second?). If you send all your geometry, color and texture data to the video card on every frame, your performance will be very bad because sending large amounts of data to the video card is very expensive. The more data you can store permanently in video memory, the better your performance will be (until you get limited by triangle throughput). So we had to find a way to store as much data as possible in video memory and just execute simple drawing instructions on every frame.

Of course, OpenGL provides several ways to do this. The first and oldest approach is to use display lists, which is basically a way to tell OpenGL to compile a number of instructions and data into a function that resides in video memory. It’s like a stored procedure that we can call every time we need some stuff rendered. The problem with display lists is that they are fine for small stuff like rendering a cube or something. 2D diagrams however consist of large amounts of arbitrary geometry, which cannot be compiled into display lists at all. So this approach was not useful for us.

The best way to store geometry data in video memory is called a vertex buffer object (VBO) in OpenGL. Essentially, a VBO is one (or more) buffer that contains vertices (and other data like colors and texture coordinates). These buffers only need to be uploaded into video memory once (or when some geometry changes) and can then be drawn by issuing as little as five commands in every frame. We decided to adopt this approach and try it for our 2D diagrams by storing the 2D primitives in vertex buffers in video memory. Rendering a 2D diagram would then be very fast and simple, because hardly any data must be sent to the video card per frame. This is how the pros do it, so it should work for us too!

In theory, that is correct. But in practice, it is very hard to actually create a vertex buffer out of the 2D content of a 2D diagram. Since a vertex buffer can only contain a series of graphical primitives (triangles, quadrilaterals, lines) of the same type and the primitives that make up the 2D diagram are drawn in random order, the primitives need to be sorted properly so that we can create large vertex buffers from them. Unfortunately, the primitives cannot simply be sorted by their type and then converted into vertex buffers because there are dependencies between such primitives that intersect. To cut a long story short, I had to think of a way to sort primitives into disjunct sets. Each set contains only primitives of the same type and each set should be maximal so that you end up with a small number of large buffers because that’s how you achieve maximum performance.

The end result is impressive: We used to have performance problems with diagrams that contain more than 2000 2D nodes, and now we can display 4000 2D nodes at 120 FPS, and all that with much better visual quality. To get an idea of how much better the quality of the 2D diagrams is in this version, check out the following screenshot:

in der Java Entwicklung, v. a. in Embedded Linux Umgebungen, gerne auch in. Frameworks wie OSGi. C und/oder Python Kenntnisse erwünscht, dazu. Erfahrung in den Bereichen Software Testing und Software Quality Assurance …

Note: There is a poll embedded within this post, please visit the site to participate in this post’s poll.

technorati tags: JQuery, poll, xpages

 

<!–

–>

<!–

–>

I have been playing with JQuery and was thinking about doing some integration with XPages components.  I have seen a few posted questions about JQuery but I am not sure how widely used it is in the Lotus community.

Note: There is a poll embedded within this post, please visit the site to participate in this post’s poll.

technorati tags: survey, xpages

Event Date: February 9, 2010 7:00 pm GMT-8

Register Now

 

Mal ohne spezfische Anwendung – aber optimal zum Erstellen eigener Anwendungen im Bereich Automatisierung und Bedienung: Leistungsfähiges Touch Panel System mit 5.7″ VGA Touch Display (natürlich TFT Farbe!), lüfterloser Embedded CPU mit 800Mhz und umfangreichen Schnittstellen. Direkt als Einbauversion für 19″ und mit Betriebssystem Linux und Java vorinstalliert. Wer will (und Linux oder Java…

Hinter jEmbedded verbirgt sich ein serviceorientierter Container (SOC), mit dem Services erstellt und verwaltet werden können, und zwar mit Hilfe von Annotations oder grafisch mit jBPM-Unterstützung. Unter anderem unterstützt …

Everyone who has ever worked with GMF knows that  it can be painful due to the steep learning curve and the tools it provides for editing the GMF models. The complexity of the models in combination with the very basic tooling makes learning and using GMF harder than it should be. Recently, efforts have been made to improve this situation. There is for example EuGenia, which was presented at the ESE 2009. EuGenia uses annotations to add information to the domain model so that the GMF GraphModel and MapModel can be generated automatically. For my diploma thesis however, I followed a different approach to improve the GMF tooling. Jens gave me the task to create a 3D graphical editor for the GMF mapping model. I would like to present the result of my efforts in this blog entry.

The basic concept for such an editor can be summed up by the following bullet points:

• The editor should display the domain model, the GraphModel, the ToolModel and the MapModel together in a 3D view.
• The models should be visualized graphically, thus a graphical notation must be developed for each of them.
• References from the MapModel to the other models should be visualized using 3D connections.
• It should be possible to edit the MapModel entirely by dragging elements from the other models (or rather, their diagrams) to the MapModel. The user should not need to use any other methods to edit the MapModel.
• The editor should create as many elements of the MapModel automatically to assist the user.

Graphical Notations

Thus, the first step was to develop graphical notations for the domain model, the GraphModel and the MapModel. The ToolModel was excluded to limit the amount of work, and it can be added at a later stage. I began by creating 2D GEF editors that simply display the aforementioned models. Obviously, with the Ecore Tools there already is a graphical notation and a very capable editor for EMF based domain models, so no work had to be done there.

Ecore Tools Editor

The main focus in creating a graphical notation for the GraphModel was to render the figures in the figure gallery just like they would look like in the generated editor. The diagram elements defined in the model should be grouped by their type (node, connection, diagram label and compartment) and the layout should be automatic, without the need for user interaction. The following screenshot demonstrates this.

Graphical Notation for the GraphModel

Developing a graphical notation for the MapModel was a little more complex because it needs to convey more information than the notation for the GraphModel does:

• The MapModel mirrors the containment relationships of the domain model (using NodeReferences, NodeMappings and Compartments) which results in a hierarchical structure. This structure should be represented visually by nesting the figures which represent the model elements.
• The MapModel needs to display additional information like which domain element is mapped etc.
• The mappings should be represented by the figures which they map to in the GraphModel. That is, if a NodeMappping maps to a blue rectangle figure (in the GraphModel), then that NodeMapping should render itself as a blue rectangle also.

Graphical Notation for the MapModel

As you can see in the above screenshot, every model element is represented using a figure that has a gray border and title bar. These figures are nested, and those figures that represent a mapping (like NodeMapping) display the referenced figure as their child. Additional information is displayed at the bottom of some of the figures in the form of a list of named properties. CompartmentMappings are nested into the figures to which they belong and contain the child references that link to the contained domain model elements.

With all the graphical notations in place, the next step was to combine those into a 3D multi editor. In order to do that, the 2D GEF editors had to be 3D-fied first. A 3D version of the Ecore Tools already exists as a GEF3D example, so that was just reused here. The other editors could be easily 3D-fied by adapting four classes each.

Multi Editor

Combining the three viewers into a multi editor also is a pretty easy task with the tools that GEF3D already contains. There is an abstract base class (AbstractMultiEditor3D) for multi editors that allow any editor implementing the interface INestableEditor to be embedded. There are only very few things that need to be taken care of manually here, like for example making sure that all embedded editors use the same EMF ResourceSet to load their models. Once everything is in place, a multi editor is used by opening one of the models using the newly created editor and dragging the other models onto the editor window – easy! The result of this step is displayed in the following screenshot.

Multi Editor for the Mapping Model

As you can see, this version of the editor already displays references from the MapModel to the other models using 3D connections. This has been implemented by using the UnidirectEditPart3D base class that comes with GEF3D. This class allows creating connections that are created by either the source or target edit part, which is exactly what was needed in this situation, since neither the domain model nor the GraphModel are aware of any references that a MapModel might have to their elements.

Dropformations

At this point, all that is missing from the editor is the actual editing functionality. It was decided to use a model transformation language to implement the editing functions (which always modify the MapModel in some way). This transformation language is called Mitra was created by Jens von Pilgrim for his Ph.D. thesis. Mitra is an acronym that stands for “Micro Transformations”. The language is optimized for fine-grained, semi-automatic model transformations, as the name indicates. Since the Mitra rules that implement the editing functionality are triggered by drag and drop operations, a GEF tool is needed that can do this. Generally speaking, a drag and drop operation can also be interpreted as selecting a number of parameters for a rule. The model elements that are dragged are called source parameters while the model element which the elements are dropped on is a target parameter.

Consider the following example: Say you want to create a LinkMapping. For this you need a connection from the GraphModel and a domain element that represents the association in the domain model (this could be either an association class or a simple reference). For the sake of simplicity, let the association be modeled by a reference in the domain model. Now to create a LinkMapping, you can drag the connection from the GraphModel and drop it on the MapModel. This creates a new LinkMapping. To set the link feature, you would now drag the association from the domain model and drop it on the LinkMapping, etc.

There is one remaining problem however: How are the transformation rules selected? Currently, whenever an element is dropped, a popup menu is displayed that contains all rules defined for the editor. This is demonstrated in the following screenshot.

Rule Selection Menu

Obviously, this is not optimal, and there are plans to implement automatic rule selection by matching the parameter types against the rule signatures, but this is still on the todo list. But even if this is implemented, there will be cases in which there are multiple rules that match the parameter types, and in those cases, the rule name should be replaced by some more meaningful names in the menu.

Demonstrations

Unfortunately, the community blogs don’t seem to allow embedding youtube videos, so you’ll have to follow this link to see how a TopNodeReference (including a NodeMapping, LabelMappings and CompartmentMappings) is created simply by dragging a Node from the GraphModel onto the MapModel. Note that no references to the domain model are set – to see how this is done you can watch this video. Finally, this video demonstrates how to create a ChildNodeReference inside an existing CompartmentMapping and a LinkMapping.

Kristian Duske

Wir suchen für einen Projekteinsatz mehrere Embedded Java Entwickler. Bewerben Sie sich bis zum 16.02.2010. Projekt von projektwerk.