As I mentioned yesterday, we want to encourage people to tell their Eclipse story.  Last week Cell Biosciences told their story at the Eclipse Day at the Googleplex.   You can view their entire presentation but I have added a summary on the Eclipse Story wiki and below.

btw, Cell Biosciences is looking a great Eclipse developer to join their team.  Check out the presentation for details.

Eclipse Story

Title: Protein Analysis with Eclipse RCP

Name: Cell Biosciences

Cell Biosciences is a company that provides instruments and software to analyze the proteins in the human body. Their systems help life science researchers in research institutions and pharmaceutical/biotechnology companies.

Cell Bioscience uses Eclipse RCP to create desktop applications to analyze the data sent from their imaging machines. The RCP based application use allows researchers to setup, run and analyze data experiments. The applications feature graphs, images and tables of data that can be sliced in different ways.

In addition to RCP, Cell Bioscience uses Eclipse as their development tool platform. Their systems include Java, Python, Javascript and C/C++ code. To support their development needs they use PyDev, Subclipse, Egit, JUnit, SWT Bot, TPTP Test and Performance, WTP WSDL editing and Aptana for Javascript.

Do we need another logging framework in the Java/Scala world? Certainly not! As Scala is fully "downward" compatible to Java, we can use whatever Java logging solution we want. And there are many, aren't there?.

So why SLF4S? Well, SLF4S isn't another logging framework, but a very thin Scala wrapper around SLF4J which has emerged as the leading Java logging solution. Why do we need a Scala wrapper for SLF4S? Well, there are some nice Scala features that can make logging even easier and/or more performant.

First, SLF4J Loggers use by-name parameters which are only evaluated if needed/accessed. When logging "traditionally", we often create messages by concatenating Strings or using the String.format method, even if we don't need these messages in the end because the logging level is not enabled. Of course we could "manually" check whether the logging level is enabled, e.g. by calling logger.isDebugEnabled, but we often don't, because it's cumbersome. With by-name parameters we can simply call our log methods and let SLF4S check whether the log level is enabled. Just take a look at one example:

def debug(msg: => String) {
 require(msg != null, "msg must not be null!")
 if (slf4jLogger.isDebugEnabled) slf4jLogger debug msg
}

class MyClazz extends SomeClazz with Logging
  ...
  logger debug "SLF4S just rocks!"
  ...

In ECF's Helios release, we released an implementation of the OSGi remote services standard specification (chapter 13 in compendium).

In addition to the full spec implementation...which is based upon synchronous remote service proxies...we added support for asynchronous remote services. This provides non-blocking access to remote OSGi services. This gives remote service consumers choices...allowing them to invoke remote services synchronously (i.e. by making a blocking method call on the proxy), and/or asynchronously (with a guarantee that the calling thread will not block).

I think that one nice thing about this approach is that the service host implementer has to do exactly nothing to make these consumer choices available. The implementation of the service host is exactly the same.

There are two styles of asynchronous access supported: an asynchronous callback (like GWT), and a future result, from the Actor model of computation. These two styles of of asynchronous access...along with the specified synchronous proxy...provides remote services consumers with some useful choices for creating reliable distributed systems and applications.

I’ve been starting a lot of documentation work lately for the EGit/JGit projects and happened to come across this timely article from Forbes. If you don’t want to read it, the gist of it is that solid documentation is more important than you think… especially when it comes to attracting a user and developer base. Here are some quotes…

“I can report that my company receives 70% plus of our site traffic from organic sources, and our documentation generates more than half of our overall site traffic. Furthermore, over half of our lead generation is driven by our documentation.”

While the article specifically mentions commercial software, I think the lesson of having solid and findable documentation apply to the open source realm. I mean, when’s the last time you’ve come across an open source project that you praised their documentation efforts? I can maybe count two total in my lifetime. As open source developers and project leads, we tend to put documentation last and our expectation is that users would pitch in to help. As users, we just want good documentation and don’t believe it’s our responsibility to help out necessarily…

So next time you’re working on that feature, weigh it versus taking some time to document things for your users. If you’re in Eclipse land, feel free to take a look at our documentation guidelines and some examples on how to crowdsource your documentation efforts a bit.

BIRT has many ways to include images within a report. Images can be used in BIRT styles, as watermarks, in text elements, and placed within the report using an image report item. In this post I will cover some of the details needed to work with images that are inserted using the Image report item.

The image report item can retrieve images in four different ways. 1 -Through a URI, 2 – as an image in the resource folder, 3 – as an embedded image, 4 -or by using a dynamic image. Each of these methods is described below with examples. In addition some of the examples use onCreate scripts written in JavaScript. While these examples use JavaScript, they could also have been written in Java.



URI Images
The first way is to retrieve an image with the image report item is to use a URI specification. This method is pretty straight forward and the value can be entered as a constant or as a JavaScript expression. Constants are processed faster by the engine but are harder to make dynamic. An example of a constant expression for a URI image would be as follows:



http://www.eclipse.org/eclipse.org-common/themes/Nova/images/eclipse.png  

if( params["dynamicimage"].value == true ){
"http://www.google.com/intl/en_ALL/images/srpr/logo1w.png";
}else{
"http://www.eclipse.org/eclipse.org-common/themes/Nova/images/eclipse.png";
}
This expression checks the value of the dynamicimage report parameter, and then based on its value, sets the value of the URI.
The URI can also be set using an onCreate event handler for the image report item.  The syntax for this approach would look like:
this.URI = "http://tomcat.apache.org/images/tomcat.gif";

//for a local file use: 
//this.URI = "file://C:/test/birtlogo.png";  

if( row["QUANTITYORDERED"] > 30 ){
"green.png";
}else if( row["QUANTITYORDERED"] > 25  && row["QUANTITYORDERED"] <= 30){
"yellow.png";
}else{
"red.png";
}  

var myqty = this.getRowData().getColumnValue("QUANTITYORDERED");
if( myqty > 30 ){
 this.file = "green.png";
}else if( myqty > 25  && myqty <= 30){
 this.file ="yellow.png";
}else{
 this.file="red.png";
}  

var jarfile = reportContext.getResource("birtimages.jar");
myfulljarimage = "jar:"+jarfile.toString()+"!/green.png";
myfulljarimage;  

this.imageName = "eyellow.png";  

importPackage(Packages.java.io);
importPackage(Packages.java.lang);
importPackage(Packages.java.net);
importPackage(Packages.javax.imageio);

//File Based
//var myfile = new Packages.java.io.File("c:/test/green.png");
//var img = ImageIO.read(myfile);  

//URL Based
//Jar image in resource folder
var jarfile = reportContext.getResource("birtimages.jar");
var myfulljarimagestr = "jar:"+jarfile.toString()+"!/red.png";
var myurl = new Packages.java.net.URL(myfulljarimagestr);

//Image in resource folder
//var myurl = reportContext.getResource("green.png");

//Image at url
//var myurl = new Packages.java.net.URL("http://www.eclipse.org/eclipse.org-common/themes/Nova/images/eclipse.png");

var img = ImageIO.read(myurl);
bas = new ByteArrayOutputStream();
ImageIO.write(img, "png", bas);
this.data = bas.toByteArray();
  

The Swiss Railway SBB has just recently joined the Eclipse Foundation as an Associate Member.

Transporting 327.5 million passengers and 50 million net tons of freight every year the company is by far the biggest travel and transport company in Switzerland.

Having experienced their great services for the time I was living in Switzerland I appreciate very much that this very service oriented organization has become a large consumer of the Eclipse platform and Eclipse related services.

We have seen presentations of their applications on various occasions such as the Eclipse Summit, and we look forward to an even closer relationship with SBB through the newly signed membership.

I'm happy to report that I've been given company approval to port the relevant components of our Flex data binding library back to Eclipse Data Binding.

I haven't started the actual port yet--there are still some concepts on the Flex side that are not a perfect match to Java and existing idioms in Eclipse Data Binding. You'll see what I mean.

To avoid conflating the port to Java with the general API I'm going to just present what the Flex API looks like.

  Bind.from(source, "foo")
      .to(target, "bar");

This binding watches the source.foo property, and writes the new value to target.bar each time a change it detected. Now add some validation and conversion magic:

  Bind.from(source, "foo")
      .validate(Validators.stringToNumber)
      .convert(Converters.stringToNumber)
      .validate(Validators.greaterEqual(0))
      .validate(Validators.lessThan(10))
      .to(target, "bar");

Here we've added several additional steps in the pipeline.

• After source.foo changes, we first validate that the string can be converted to a number. If so the pipeline continues to the next step, and terminates otherwise.
  
• Next we convert the string to a number
  
• Now validate that the number is greater than or equal to zero. If so the pipeline continues to the next step, and terminates otherwise.
  
• Now validate that the number is less than 10. If so the pipeline continues and the number, now verified to be in the range [0,10), is written to target.bar.
  

Now suppose our binding is misbehaving somehow, and we want to troubleshoot. We can add logging steps to the pipeline in between the other steps so we can see exactly what is going on:

  Bind.from(source, "foo")
      .log(LogEventLeven.INFO, "source.foo == {0}")
      .log(LogEventLeven.INFO, "validate {0} is a number")
      .validate(Validators.stringToNumber)
      .log(LogEventLeven.INFO, "convert {0} to a number")
      .convert(Converters.stringToNumber)
      .log(LogEventLeven.INFO, "validate {0} >= 0")
      .validate(Validators.greaterEqual(0))
      .log(LogEventLeven.INFO, "validate {0} 

      .validate(Validators.lessThan(10))
      .log(LogEventLeven.INFO, "set target.bar = {0}")
      .to(target, "bar");

(In Flex, string formatting is done with {n} format instead of the %s syntax which Java inherited from C. The log statement passes the values in the pipeline as additional arguments which you can reference in log statements.)

These log steps are a real lifesaver for tracking down and squashing bugs in your binding code.

If you've already worked with Eclipse Data Binding you may have noticed something else: you are no longer constrained to the standard data-binding pipeline. You are free to add steps in the pipeline wherever you like and in any order you like.

Next up is two-way bindings. The bind class provides a twoWay method which connects two bindings to the other one's starting point:

  Bind.twoWay(
      Bind.from(source, "foo"),
      Bind.from(target, "bar") );

is equivalent to:

  var lock:Lock = new Lock();
  Bind.from(source, "foo")
      .lock(lock)
      .to(target, "bar");
  Bind.from(target, "bar")
      .lock(lock)
      .to(target, "foo");

Notice that each binding has a "lock" step in the pipeline. Only one binding can hold a lock at a time. This solves the common infinite loop problem:

• source.foo changes. binding one executes, writing the value to target.bar
  
• target.bar changes. binding two executes, writing the value to source.foo
  
• source.foo changes. binding one executes, writing the value to target.bar
  
• ...
  
• stack overflow!
  

Since only one binding can hold the lock at a time, this is what happens instead:

• source.foo changes. binding one acquires the lock and executes, writing the value to target.bar
  
• target.bar changes. binding two attempts to acquire the lock but it is already acquired. binding two aborts.
  
• binding one releases the lock
  

You should never add the same lock more than once to a single binding, since that would guarantee that the binding will never run.

Two-way bindings can use validations, conversions, logging, locks etc just like regular one-way bindings (since two-way bindings are just two one-way bindings wired up to eachother):

  Bind.twoWay(
      Bind.from(person, "birthDate")
          .convert(Converters.dateToString(dateFormat))
      Bind.from(heightText, "text")
          .validate(Validators.stringToDate(dateFormat))
          .convert(Converters.stringToDate(dateFormat))
          .validate(Validators.lessEqual(now))
      );

We usually leave out the validations in the model-to-UI bindings. It's usually only important to apply validations when you're copying data back from the UI to the model, to make sure domain constraints are satisfied, such as ensuring that a birth date occurred in the past.

And now for my favorite part: binding from multiple sources, to multiple destinations. Raise your hand if you have ever had to wire up a UI form like this:

  Is there a foo? (o) Yes  ( ) No <-- fooRadioGroup

  Enter bar: ____________________ <-- barText

Requirements:

1. fooRadioGroup.selectedItem is bound to model.foo (a boolean)
   
2. barText.text is bound to model.bar (a string)
   
3. barText must be enabled iff fooRadioGroup selection is Yes.
   
4. When the user clicks "No," set model.bar to null but do not clear the text box. If the user clicks "Yes" again, set model.bar back to the contents of barText
   

Requirements 1 and 3 are easy:

  var fooLock:Lock = new Lock();
  Bind.twoWay(
      Bind.from(model, "foo"),
      Bind.from(fooRadioGroup, "selectedItem"),
      fooLock); // explicitly provide the lock, see more below

  Bind.from(fooRadioGroup, "selectedItem")
      .to(barText, "enabled");

Requirements 2 and 4 are kind of related to eachother. The model-to-UI binding is simple enough: just write the value straight across:

  var barLock:Lock = new Lock();
  Bind.from(model, "bar")
      .lock(barLock)
      .to(barText, "text");

However the inverse binding (UI-to-model) must also take fooRadioGroup.selectedItem into account to decide whether to write back barText.text (if Yes is selected) or null (if No is selected).

The Bind class has another trick up its sleeve:

  Bind.fromAll(

      Bind.from(fooRadioGroup, "selectedItem")
          .lock(fooLock),

      Bind.from(barText, "text")

      )
      .lock(barLock)
      .convert(function(foo:Boolean, bar:String):String {
        return foo ? bar : null;
      })
      .to(model, "bar");

Look closely. The binding pipelines that we pass to fromAll(...) become the arguments, in the order they are provided, to the converter and validator functions further down the pipeline. The first pipeline is from fooRadioGroup.selectedItem and therefore that boolean value is the first argument to the converter. Likewise, the barText.text pipeline is provided second, so that string value becomes the second argument to the converter.

The converter takes multiple values but returns only a single value. This is where those values get coalesced into a single value that we can write to the model--in this case, a String value or null.

The outer pipeline adds a locking step on barLock, which is expected since we need to prevent infinite loops between the last two pipelines. However we are also locking on fooLock, on the first of the inner pipelines. We had a problem with our bindings overwriting values in the UI depending on the order things were initialized.

It turned out that without that lock, if a new model object was set, then the foo binding would fire first. Thus model.foo was copied to fooRadioGroup.selectedItem. But that would trigger our last binding to execute, so if the new foo value was false, then the last binding would override anything in the text box and set null on the model.bar field, before the model.bar => barText.text binding had a chance to execute!

A good rule of thumb is that any time you need to bind from multiple sources, you should make sure to create a lock to share between all the bindings to relate to the same field in the model.

Obviously there are several concepts that will have to be adapted to work elegantly with our existing APIs. Realms are a missing piece (Flex is single-threaded so we didn't even have to consider it). Also we would want to try to retrofit the existing binding classes to use this new API transparently, like we did with the transition from custom observables to custom properties.

So there you have it. This is my current vision of what Eclipse Data Binding should evolve toward.

Comments?

If anybody is going to be in Dublin next Thursday (Sept 9th), I’ll be talking about OSGi, Software Modularity and Single Sourcing.  Details of the event can be found here. If anybody is going to be in the area, let me know. I’d love to catch up with some Eclipse folks over a few frosty beverages.

I know Eclipse ‘Help’ is not a very exciting topic, but today I found myself working with a little known secret of Help.  Most people know that you can setup context sensitive help (Press F1 and bring up help for the specific workbench part under focus).   However, did you now you do the opposite?  That is, activate code in your RCP application from a link in Help?

Here’s the use case:  Say you have created a chat client built on the Eclipse RCP Platform.  Like any good software engineer, you’ve created extensive help content.  In addition to Instructions, you want to provide links that actually open the dialogs, or perform the actions. Active Help is the solution.

In this example, I’ve added a link that opens the “Add Contact” dialog, directly from the “Adding a Contact” Help page.

Doing this is extremely simple too. On the Java side, you simply need to implement the ILiveHelpAction.  Then, on the help side you simply add the following JavaScript to your help contents:

<a href='javascript:liveAction(
	"org.eclipsercp.hyperbola",
	"org.eclipsercp.hyperbola.ActiveHelpOpenDialogAction",
	"")'>Click here for a Message.</a>

The only thing to keep in mind is that the Action is not executed on the UI thread, so you may need to synchronize this yourself.

I’ll continue my instructions regarding how to set up JSDT development infrastructure.

Previously

• I set up the build target
• I checked out the code
• I updated to the latest debug plugins to resolve compilation issues.
• I launched the unit tests

Now run the product

When I work on Eclipse products, we typically provide a default launch config per product.  Although the nightly build is the ultimate authority of what encompasses the product, these version-controlled launch files provide a good point of comparison developer to developer.

I could not find a public JSDT .launch file under CVS control.

So I looked at the installed JSDT product to create my own.  It’s here if you would like to download it.

Just drop it into an active project in your Eclipse workspace, refresh the project, open ‘Run Configurations” and you should see a “jsdt” run config.

You may want to tweak it a bit and verify that the set of selected plugins is correct.

Then hit Run to see the JSDT.

Disclaimer: I’m not on the JSDT team, so this may not be exactly how they do it. But it’s what I’ve done to get it working.

Lots of people are doing incredible things with Eclipse. People are building amazing applications that embedded Eclipse technology. Companies have standardized on Eclipse as their development tools platform. Students and researchers are using Eclipse for creating some very cool new technology.

As with any open source community, sharing information is critical to fostering  a healthy and strong community. Sharing how you use Eclipse will help other people realize the full potential of Eclipse technology.  More people using Eclipse technology will lead to more potential contributors, more contributors mean more people working on Eclipse projects.

We want you to share your Eclipse story with the community. I’ve started a wiki page to allow individuals and companies to tell the community how they use Eclipse. Tell us what type of applications you build, what Eclipse technology you use and what you like about Eclipse. You can tell us your personal story or tell us what your company is doing. Just tell us your story.

To encourage early stories, the Eclipse Foundation will raffle off a full pass to the upcoming JavaOne 2010 conference to all who submitted a story. To be included in the raffle you need to submit your story on the wiki by September 9, 2010 at 1:00pmET and send me an e-mail (ian at eclipse dot org)

Last night I had the pleasure to speak at my local AustinJUG.

It was nice to catch up with some local folks and introduce people to some new Eclipse technology. In the end, we kind of got sidetracked and there was some good discussion about source control in the corporate environment versus what is going on in open source communities. Unfortunately, it seems Subversion has a stronghold in a lot of companies still. I hope our work in JGit to make a liberally licensed Git library that runs everywhere will start swaying the tide…

Dunge: Hello there, sorry for the noob question. I installed Eclipse for Java (Helios) and JDK update 21, I’m trying to use the Blackberry SDK but when I install it it say I require org.eclipse.jdt.debug [3.5.0,3.6.0) first. I tried to find it in “install new software” or on the website, I can’t find anything
rcjsuen: Dunge: That BB plug-in wants Galileo not Helios.
rcjsuen: “require org.eclipse.jdt.debug [3.5.0,3.6.0)”
rcjsuen: Dunge: 3.5.x corresponds to Galileo, 3.6.x corresponds to Helios
Dunge: rcjsuen : you say 3.6.x for Helios, and they actually write 3.6.0 in the required message, so why should I revert to 3.5.0?
rcjsuen: Dunge: You must not have taken Calculus, or forgot about it.
rcjsuen: [x,y) means x inclusive, y exclusive
rcjsuen: i.e. 3.5.0 <= x < 3.6.0
Dunge: should be [x,y[
rcjsuen: Dunge: I’ve never seen that notation. Where do they do that?
Dunge: I just though it was a typo
Dunge: hmm in my math classes? :)
rcjsuen: [x,y[?
Dunge: yeah
rcjsuen: Dunge: And where do you live? That’s what I meant. :)
Dunge: lol
rcjsuen: Dunge: I am interested in where they use this notation, hence I asked.
Dunge: I just asked the guy next to me and he’s saying it should be a [ too
Dunge: I’m in Quebec
rcjsuen: ah
rcjsuen: in the States they used this
rcjsuen: and I went to U Waterloo, we used that there too
Dunge: but I though it was a global notation
rcjsuen: I shall ask other ppl when I get back to Ottawa on Sunday :)
rcjsuen: Maybe that is what they use in France/Europe?
njbartlett: rcjsuen: Possibly France, but certainly not other bits of Europe
rcjsuen: That notation seems to be part of the ISO anyway http://en.wikipedia.org/wiki/ISO_31-11#Sets
rcjsuen: Very interesting. You learn something new every day as I always say. :)
njbartlett: Indeed, very interesting.
rcjsuen: njbartlett: So I think we need language packs for fr_FR that uses different notation. :)
njbartlett: I’ve given talks about OSGi in lots of countries, almost everywhere there’s at least one or two maths geeks who nods quietly when they see [,)
rcjsuen: hahahaha

We are happy to announce that the EMFStore project has been accepted as an Eclipse Project.
www.emfstore.org

We are happy to announce that the EMF Client Platform project has been accepted as an Eclipse Project.
www.emfcp.org

Not many votes (about 20 or so at time of reading), but Google App Engine seems to be a big favourite for Eclipse users, gathering half the votes by itself.

Looks like I have some reading up on Google App Engine to do…

Continuing our series on the perfect Android tablet ™, this latest entry is about software instead of hardware. Software applications will either make your tablet into a useful addition to your digital life, or an expensive ingredient in some eco-unfriendly compost pile. Finding the right software is crucial, and for that reason the number three feature on the perfect tablet is:

#3: Full Google software suite including the Android Market

Many recently announced Android tablets come with an alternative application stores such as AppsLib, GetJar, SlideME, or AndAppStore. Alternate markets are good to have for applications that are not allowed, for one reason or another, on Google’s mainstream Android capital-M Market. However, it’s the Market that has 100K+ applications and it’s the Market that is both the de facto and de jure center of the Android development universe.

For a one-time fee of $25, developers can get a publisher’s account on the Market and upload their free or paid applications. The Market is fraught with problems, such as tons of spam, a stingy 325-character limit on descriptions, and a woefully lacking list of supported countries. Google has been ever-so-slowly improving the Market over the last couple of years, for example by adding the amazingly innovative ability to post screenshots (insert sarcasm here). The fact that it’s flawed, though, doesn’t change the crucially important role of the Market in the Android ecosystem.

As a developer, I want to submit my application to one place and have it reach all users. I can do that with the iPhone, so why not on Android? (Of course Apple brooks no alternatives on the iPhone, so it’s not a fair comparison, but still there should be a default market that covers everyone.) Each additional place I have to publish is another place I have to make a publishing agreement with, keep up to date for each upgrade, and manage for marketing. More potential users with less friction for the developer equals more income and more interest in creating exciting games and applications.

Perhaps the greatest impediment to the universal Market is a somewhat nebulous list of restrictions and requirements that Google imposes which limits what types of devices can and can’t have the Market and other Google apps. Some of the restrictions I can understand, like requiring an accelerometer. Others make no sense, such as the need to include a telephone (with its requisite expensive monthly fee). Google needs to change these rules ASAP or at least show some flexibility to accommodate devices (such as as the 5 announced this week from Archos) that aren’t smartphones.

Along with the Market, the perfect tablet should have all the other parts of Google’s Android suite, including GMail, Maps, Navigation, Search, and so forth. The apps should either be pre-installed or available for download through the Market. This does not preclude a vendor from using, say, Bing search and Yahoo Mail by default to differentiate their offering. But Google’s suite is pretty good, and I ought to be able to use it if I want without having to search the fine print for the words, “with Google”.

What would you build into *your* perfect Android tablet? Share your thoughts in the comment area below. And check back next week to find out what’s next on my list.

I’ll continue my instructions regarding how to set up JSDT development infrastructure.

Previously

• I set up the build target
• I checked out the code
• I updated to the latest debug plugins to resolve compilation issues.

Run the unit tests

Now I want to verify that the unit tests for JSDT pass.  (TDD — we should launch the tests before the product, right?)

Nitin Dahyabhai, the JSDT lead, pointed out that the first project above, contains a launch config to run all of the JSDT unit tests.

I will need to check out these additional projects from the webtools CVS repository.

• org.eclipse.jsdt/development/org.eclipse.wst.jsdt.unittests
• sourceediting/tests/org.eclipse.wst.jsdt.web.core.tests
• sourceediting/tests/org.eclipse.wst.jsdt.web.ui.tests

The checked in launch config makes running easy.  Open Run Configurations – select JSDT Tests.  Hit Run.  They all pass, so I see green:

Next: Launching the Product

Disclaimer: I’m not on the JSDT team, so this may not be exactly how they do it. But it’s what I’ve done to get it working.

I’ve been documenting how to use JSDT to do some HTML5/CSS/JavaScript development. In order to poke around the JSDT code to understand it better, I spent a bit of time figuring out how to get things checked out, built and running. The instructions on the JSDT site a re a bit sparse, so I thought I would document what I did.

I’m not on the JSDT team, so this may not be exactly how they do it. But it works for me.

Previously

• I set up the build target
• I checked out the code

My code no longer compiles!

This morning, I updated all the code I previously checked out.  And now my rhino.ui project has a compilation error in RhinoTabGroup:

After a little investigation, I determined that RhinoTabGroup is using a new 3.7 method in AbstractLaunchConfigurationTab.  It has just been introduced.  I’m building against Eclipse 3.6, so don’t have this method.

So if I want to keep my JSDT source code in sync with the latest, I’ll have to also keep up with any dependencies.

One idea to resolve this would be to download the latest milestone builds and put them in my build target.  However, this change is very recent and is not in a milestone build yet.

Another idea is to check out the latest o.e.debug.ui project and any dependency projects (hopefully not too many).

Check out more projects

To add the eclipse CVS repo, copy this into the CVS Repositories View:

:pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse

And check out org.eclipse.debug.ui and org.eclipse.debug.core projects

And the compilation issue is resolved.

Going Forward

Going forward, my build target and workspace projects will change often.  I’ll need to actively modify these to keep things rolling along.  I’ll be doing a combination of:

1. Including other Eclipse projects in my workspace, on an as-needed basis.  I’ll start getting a good sense of what these projects are as things break.
2. Change my build target to move up to Milestone builds.

Next: Launching the JSDT Unit Tests

Some of you may have noticed the debate happening regarding proper entry expectations for WTP incubator project following Holger’s veto of a committer election. Holger is acting well within the power granted to him by Eclipse Development Process (EDP), but is it a right and proper action?

Every committer on a project has the veto power in an election. By extension, any entry criteria for a project (whether written or unwritten) is nothing more than a social convention. The reality is that every committer can choose to levy their own personal expectations. Most of the time it’s not a problem, except when it is.

Here are some quotes from this particular event:

“I found only some bug reports but not a single code contribution from any of the four nominated persons. Please attach the planned code contribution to a bug report. I'd like to vote for each of the nominated persons as soon as I know that the code is readable and covered by JUnit tests.”

“Have [snip] been asked if they like to become committers as individuals (and not only as employees of SAP)? Are these authors of the code or what is their motivation to maintain and enhance these editors?”

In a regular project with established code base, established team and well-defined scope, you can argue that giving every committer veto power over elections is appropriate. After all, there is an established code base to protect. The same considerations do not apply when a new component is proposed in an incubator.

The WTP incubator project was started with the intention to provide a low entry barrier playground for people to come and experiment on new ideas while gaining experience and proving their merit to committers on the core projects that will eventually be asked to admit matured functions. Incubators make sense because they provide a quicker way to get started than a separate project proposal. Unfortunately incubators have to rely on a social convention that existing committers act in a welcoming fashion to newcomers. Most of the time that happens, except when it doesn’t.

I would posit that there is no legitimate purpose served by holding a committer election when a new component is proposed for an incubator. The situation is supposed to be very similar to new project creation and we don’t hold elections there. The party proposing a project gets to designate a group of individuals to be the initial committers without anyone questioning their credentials or motives. A similar process is needed to make incubators work better.

The last revision of EDP has formalized the concept of a persistent incubator. I propose that we build on those revisions and amend EDP to remove the committer vote requirement for incubator projects when a new component is being proposed. The project’s PMC would still have the oversight and ability to decline a new component proposal. This change would also fix the rather awkward problem of having to have “seeder” committers when creating incubator projects.

Note that my suggestion is for persistent incubator projects rather than normal projects during incubation phase. I am also not suggesting that we remove committer vote entirely from incubators. Anyone wishing to join existing effort already underway in the incubator should still be subject to committer vote.

Thoughts?

PS.1 : This situation has served to highlight a process problem and it is the process that I seek to improve. I have no beef with Holger. I am sure he is acting on what he believes in.

PS.2 : I am further confident that this particular storm will blow over, Holger’s objections will be met, another election held, etc. That doesn’t mean we shouldn’t try to improve the process so that such situations do not happen again and we continue to have vibrant incubator projects at Eclipse.

Update: At Wayne’s request I created a bug to track this proposed improvement to Eclipse Development Process.

Last Thursday, Google was the host of the third Eclipse Day at the Googleplex.  I look forward to this event each year and this year was another success.  Over 150 people attended the day long event that included 12 sessions related to Eclipse and Google technology.   The presentations are now available online.   There was lots of great information presented, like upcoming improvements to the Android SDK (based on Eclipse), Git support in Eclipse, a review of the Instantiations tools that Google just purchased and an introduction to the new Tools for Mobile Web project.
The event also included our first ever Eclipse Ignite session.  We had 9 speakers, each speaker had 5 minutes and 20 slides but the slides changed automatically every 15 seconds.  The speakers did a great job and lots of people really enjoyed the format.  Something to certainly try again.

A special thanks to the Google Open Source Program Office for their sponsorship of the event.  These face to face events are really important to building the Eclipse community, so it is great to have Google’s support to make this event possible.

The final re-post to remind you to use the feeds from JBoss Tools to get JBoss tooling news ;)

Blogging about upcoming webinar tomorrow, the Cloud efforts and bringng back life to a BPEL project.

See it at JBoss Tools Blog

I’ve used target platforms to ensure that I only add dependencies that are available in our build platform. Until now, I found them useful, but I did not understand how powerful they really are. Here is a story that convinced me that target platforms are a master feature of RCP development.

A few days ago, I had to fix a bug on the 5.2.3 branch version of the Studio/RCP part of Bonita Open Solution. The classes I needed to modify had been strongly refactored in trunk (5.3), so that the fix would be different on the trunk than on the branch, and it was impossible to simply propagate a fix.

So I had to edit old code. But my workspace only contained trunk code, and the old code was not compiling because of several refactorings. I was wondering how the heck I would be able to easily work on code from the past…!
But I found an answer and it’s simple… TARGET PLATFORMS !

Here is what I suggest to isolate the branch fix from trunk development:

1. Create a new workspace (workspaceBranch).
2. Set the old version of your product (here the 5.2.2 version) as the target platform. This must be the version containing the bug.
   

   The target platform is made up of all bundles of the product containing the bug

3. Check out ONLY your old bugged bundle from the branch.
   

   A minimal and easy-to-use workspace

4. Create your launch configuration which is made up of the product and your buggy bundle project from workspace.
   

   Configure your launch to use your product, with the patched bundle from your workspace

5. Run and test your product to see the bug.
6. Fix your old code.
7. Test your fix.
8. Commit your fix on the branch.

With this trick, I avoided the headaches of mixing trunk and branch code. It made my work much easier and less risky.

The only annoying thing is that you lose all your workspace preferences and Mylyn contexts during the time it takes to finish the fix, so this is not critical.

I can now say it: I ♥ target platforms!

According to this post of Christian Halstrick and those two commits: 1 2. The upcoming version of JGit and EGit would have merge support! The previous stable version (0.8) had only support for fast-forward merge; all non fast-forward merges must be done using CGit, now all kinds of merge can be done using EGit UI.

The 0.9 version would have more cool features eg. History view improvements, branch and tag dialog improvements and (of course) support for Synchronize view. Say tuned for a full list of new and noteworthy that will be published in upcoming days.

Just tried the brand-new resolve merge strategy Christian Halstrick worked on hard in the last months which finally got submitted today after months of testing, reviewing and refining the implementation.

I created a simple test project and changed a simple class in two different ways on the branches “first” and “second”. Then I successfully fast-forward merged branch “second” into branch “master”. Then I hit “Team > Merge” to run the shiny new resolve merge strategy to merge branch “first” into “master”. And here we go: the merge tried to merge the content and detected the conflict:

EGit resolve merge with conflict

Give it a try and let us know if you hit any problems, we will work on improving the user interface
and of course also plan to integrate it with a visual merge view.

The Eclipse Foundation and Eclipse member companies are pleased to announce the fall 2010 training class series. The training is an excellent opportunity for software developers and architects to learn more about Eclipse Rich Client Platform (RCP), BIRT and Modeling technologies. Eclipse experts will lead the sessions, providing practical experience through classroom instruction and hands-on labs. Virtual and on-site classes have been scheduled in several countries from September 20 to November 5, 2010.

 82: @org.codehaus.groovy.grails.web.transform.LineNumber(
  83:  lines = [3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 3, 6, 6, 6, 7, 7, 8, 8, 9, 9, 9, 9, 9, 10, 10, 10, 11, 13, 13, 13, 13, 13, 13, 14, 14, 14, 14, 14, 17, 17, 18, 18, 19, 19, 20, 21, 23, 23, 23, 23, 25, 25, 26, 35, 35, 35, 35, 37, 37, 37, 39, 39, 39, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1],
  84:  sourceName = "create.gsp"
  85: )
  86: class ___LineNumberPlaceholder { }

Since beginning of last year I participate more or less actively in the Java User Group Mannheim. Unfortunately the former main contact of the Java User Group Mannheim Alex Hanschke has moved out of the area.

Benjamin Muskalla and myself volunteered to help organize the JUG Events. Therefore Benny and I will as of now try to find great new speakers and setup cool events. I think we are starting very well, as we are proud to have Matthias Sohn and Stefan Lay speak about Git and EGit on the 02.Sept. Git is one of the leading distributed version control systems and EGit a team provider for Eclipse.

Matthias and and Stefan are both committers in the EGit project. Details on Matthias and Stefan and the presentation can be found on the Majug Event Announcement. As usual we organize to have drinks after the event and hope Matthias and Stefan will be able to join so that you can bugger them with questions. The presentation will be in German.

Rumors are that we will see a real merge via EGit on this event… Hope to see you at their.

A new version can be found on the update site. The new versions of the features contain the latest fixes. New in this version is support for Jasper reports which are so far used by Bioclipse Decision Support and Bioclipse Brunn for generating printable reports.

To update go to Help -> Software Updates... and select the features you want to install.

Known problem: The splash screen erroneously shows version number to be 2.4.0 after update. (Technical information can be found at bug: 2084 in our Bugzilla)

I’m embarking on a pet project, in short: a Python-based web application using my favourite editor, Eclipse. Being quite new to this, I thought I would poll my readers, especially those Eclipse web app developers among you, for their opinions on the best solutions. I realise I’m giving very few details, but I simply want to know what’s popular, or even what is being used that I’m not aware of. Thanks.

In my previous post on “OSGi Compliance”, I discussed the idea of making libraries ready for OSGi without depending on OSGi directly. In light of BJ’s comment I will refer from now on to OSGi “Readiness” rather than Compliance, as the latter term is easily confused with the concept of a framework implementation that complies with the OSGi specification.

In each of these blog posts, I will state a requirement and then look at options for satisfying that requirement in an OSGi Ready way.

Problem Statement

You are developing a Java library, “Framework X”. Occasionally you must load and instantiate a class dynamically by name, where the name may originate from a configuration file or be passed into the framework as a parameter to an API call. You would like the framework to work cleanly both in OSGi and other environments, i.e. there must be no dependency on OSGi.

For example, suppose we are implementing an O/R mapping framework similar to Hibernate, and the user has supplied a configuration file such as the following:

<or-mapping>
   <class name="org.example.domain.Event" table="EVENTS">
      <id name="id" column="EVENT_ID"/>
   </class>
</or-mapping>

This tells our framework to create an instance of org.example.domain.Event for each row of the EVENTS table. Therefore we must dynamically load and instantiate the org.example.domain.Event class.

Discussion

To dynamically load a class in Java we require two things: the fully qualified name of the class, and a ClassLoader from which to request it. If we have both of these then we can trivially load a class irrespective of whether we are in OSGi or not.

To reiterate: OSGi does not interfere with the standard Java class loading API. If we have the fully qualified name of a class and a ClassLoader that knows of that class, then we can always load and instantiate the class.

Problems arise only when we do not know the correct ClassLoader, and make the wrong guess about which one to use.

First Wrong Guess: Class.forName()

Java provides us with a way to load a class without explicitly specifying a ClassLoader, using the single-argument version of the Class.forName() method:

Class clazz = Class.forName("org.example.domain.Event");

Since we don’t specify a ClassLoader, this method uses the loader that loaded the class in which the line of code appears. In other words, it uses the same loader that loaded the framework. In a traditional Java SE environment this usually works just fine, because both the framework and domain classes are probably installed as JARs on the classpath, and the classpath is loaded by a single ClassLoader, the so-called “system” loader.

But in OSGi, the domain classes are likely to be supplied in a different bundle, because there is a clear modular separation between the O/R framework code and the domain model classes, and therefore they will be loaded by a different ClassLoader. We can still make it work if the package org.example.domain is listed as an import of the framework bundle like so:

Import-Package: org.example.domain, ...

However this is unsatisfactory because Import-Package is statically defined, and a general-purpose O/R framework does not know in advance which domain packages it will need to import.

(NB there are a couple of other workarounds for this problem in the case that the framework code cannot be changed. These include: DynamicImport-Package; shipping the domain classes as a fragment hosted by the O/R framework; and using the Equinox-only “buddy loading” feature. However all of these workarounds have their own severe problems, which I shall not discuss in depth here because the purpose of the post is to document how to best implement a framework such that hackish workarounds are not required.)

Second Wrong Guess: Thread Context Class Loader

The Class.forName() approach fails not only in OSGi but also in other environments such as Java Enterprise Edition, for similar reasons. Because of this, another common pattern is to use the Thread Context Class Loader (TCCL), which was introduced relatively recently (i.e. Java 1.2):

ClassLoader tccl = Thread.currentThread().getContextClassLoader();
Class clazz = Class.forName("org.example.domain.Event", true, tccl);

Some libraries use the TCCL exclusively, others use it as a last resort after failing to load from other candidate class loaders. Almost every library follows a different strategy because Java has provided almost no specification or guidance on when to use the TCCL… to quote a classic JavaWorld article:

Those class and resource loading strategies must be the most poorly documented and least specified area of J2SE.

Even in J(2)EE the specifications do not lay out precisely which set of classes should be visible through the TCCL. In practice, a J(2)EE application server is able to provide a sensible set of classes via the TCCL because the programming model is highly constrained: each application runs in an isolated silo, is not allowed directly to create threads or network sockets, and threads cannot cross application boundaries. Because it controls all the entry points, the application server can provide a TCCL that is appropriate for the running code.

OSGi’s programming model is far less constrained. Bundles are free to create threads, to open network sockets, and to call APIs exposed by any other bundle. There is no way in Java to intercept a direct method call that happens to cross a bundle boundary, so the OSGi framework cannot ensure the TCCL is relevant to the current code. As a result, the TCCL is not defined by the OSGi specification, and it may be null. Therefore, we cannot rely on the TCCL for anything.

Solutions

Now let’s discuss possible solutions. To be clear, all of the following suggestions are intended to supplement rather than replace existing approaches. If your framework is working in J2SE/J2EE with Class.forName() or TCCLs then you should continue to use those approaches. But, please provide additional options for runtime environments such as OSGi where those approaches fail.

If you feel these suggestions are trivial or obvious — that is exactly the point. There is nothing complicated about making frameworks that work well in OSGi. Indeed, you may find you prefer using one of these patterns as they reduce the complexity and testing burden of your code.

Option 1 — Instance Factory

The first option is to avoid dynamic by-name class loading altogether. Although not always practical, it may be possible in some cases to allow clients to supply their own callback or factory to create objects as required.

For example our O/R mapper could define the following interface:

public interface DomainObjectFactory {
    Object createInstance(String tableName);
}

Clients could supply an instance of this factory when initialising a session, or we could wire it in with our favourite Dependency Injector. This has the advantage that clients can construct objects however they like, rather than placing restrictions on the permitted constructors in the domain classes.

On the other hand it may be risky since a client factory implementation could return shared instances, whereas the framework expects new objects on each call to createInstance(). So long as such requirements are documented, the framework should permit clients to do what they like.

Option 2 — Register Classes

Another option is to add API for clients to register loaded classes in advance. This is best illustrated in client code:

session.registerClassForTable("EVENTS", Event.class);
List events = session.createQuery("from Event").list();

Here the client code has direct visibility of the Event domain class, so it can use a class-literal to pass a Class to the framework API. The framework can now use the supplied class whenever it reads from the EVENTS table.

We can even register classes directly against their names:

session.registerClass("org.example.domain.Person", Person.class);

The framework can use the registered class whenever it needs to create an instance of org.example.domain.Person, but fall back on Class.forName()/TCCL for unregistered names. No other changes are required in the framework.

Note that with this option, the client loses some flexibility and control. By passing a class rather than instances, the client has no opportunity to construct objects in the way it wants them, but instead relies on the framework to construct them.

This is not so bad in the running example of domain objects, but suppose we are talking about some kind of “service” object. Without control over instantiation, clients cannot make the service aware of its “environment” or “context”. Sometimes this forces us to use static fields, thread-local variables or other hack to get hold of our “context” after having been instantiated by a framework.

If the framework allows pre-instantiated objects, then those objects can be pulled out of the OSGi service registry, a Dependency Injection container, or even generated on the fly. So when designing an API, please consider whether the framework really needs to take control of instantiation by requiring Class objects — if not, at least allow the option of passing pre-instantiated objects.

Option 3 — Pass the Loader

This option is the conceptually the simplest, and also has the least impact on existing code: allow clients to pass a ClassLoader into your API. The appropriate time to do this is highly dependent on the nature of the API, but in the O/R mapper it might be done during initialisation of a session:

SessionFactory.createSession(MyClass.class.getClassLoader());
// ... OR ...
session.setDomainClassLoader(MyClass.class.getClassLoader());

To minimise the impact on existing code, this method can be overloaded with another version that takes no argument. Alternatively, clients could pass null to indicate that the framework should attempt to find the right ClassLoader.

Again there is a loss of flexibility for clients since this solution assumes all classes can be loaded from one class loader, which may not actually be the case, but in practice it doesn’t create any real problems.

Summary

Although this post has been rather long-winded, the message is very simple: stop guessing.

If you are writing a library that performs dynamic by-name class loading, do not make assumptions about which ClassLoader to use. Allow client code to specify a class loader, or perform its own class loading. By all means retain your Class.forName() or TCCL-based lookups, but please provide an override for environments in which they will not work.

In our digitization wiki project based on Eclipse 4 and Scala it was time to find a persistence solution. As a quick overview of what it’s about, our app will basically allow a user to edit a digitized book page, showing the original scan as an image, with the selected word highlighted. It currently looks like this:

For the initial prototype implementation, we used XML files in zips to store the page content, combined with TrueZIP, a library which allows access to files in zips the way it should be: like files in a folder. So we could basically create and use the zip entries like this:

val zipEntry = new File("PPN345572629_0004.zip/0001.xml")

The XML is created using Scala’s XML support, e.g. the top class in our domain model (Page) is serialized by specifying the root element and calling toXml on each containing element (the words), like this:

def toXml:Elem = <page> { words.map(_.toXml) } </page>

The XML is deserialized with the reverse action, by passing the deserialized word elements contained in the root element to the Page factory method:

def fromXml(page:Elem) = Page( for(word <- (page \ "word"))
  yield Word.fromXml(word) )

So that was basically our prototypical persistence mechanism. Of course, to actually collaboratively correct our digitized texts, we needed a central DB instance on some server. Or maybe not exactly: having heard good things about CouchDB (in german), it was the first option I looked into. The distributed nature of CouchDB sounded very interesting and seemed appropriate for our project – not for performance reasons, but to provide offline or decentralized editing as an option.

So I looked into CouchDB with scouchdb, a Scala API to access it (and a very welcoming project). After input from my colleague, I became aware that we’d lose quite a bit of installation ease if we pick a non-Java DB, so CouchDB was not really a client side option for offline storage, and therefore the strongest reason for us to consider it no longer there.

Next I considered an embedded relational Java DB with some ORM or ORM-like access. A JPA solution like EclipseLink or Hibernate seemed overkill and not ideal for Scala. Instead I took a closer look at ScalaQuery, which uses Scala’s for expressions for DB queries, which seems like the thing you want if you happen to use a language that basically has a query language built-in.

For instance, in ScalaQuery, we could write a query to get all pairs of pages and words where the page contains the word and the original form of the word is Bonifaci like this:

val bonifaci = for (page <- Pages; word <- Words;
  if page.id === word.pageId && word.original === "Bonifaci")
  yield (page, word)

To allow this kind of queries, we need to define tables named Pages and Words. Defining the tables with ScalaQuery is quite elegant, e.g. our main table for pages could be defined like this:

object Pages extends Table[(String, java.sql.Blob)]("pages") {
  def id = column[String]("id", O PrimaryKey)
  def image = column[java.sql.Blob]("image")
  def * = id ~ image
}

However, this leads to either a duplication of our domain objects (have a table object as above and the original class) or a complete rewrite (use table objects like above as the domain objects), which both seemed wrong.

Also, thinking about alternatives to our XML representation, I came to realize that we would want some form of XML export anyway to ensure long-term access to our data, which is in the public domain and a cultural asset. Of course it would be possible to implement this as some form of export, but if possible it would be just perfect if we could use a single persistence mechanism.

I did remember there are some XML DBs around, but initially abandoned that idea since XML is only half of what we store (the other thing being the images used to correct the text, see screenshot above). But after being unhappy with these other solutions, I took a closer look at eXist-db, an XML DB licensed under the LGPL which by default runs on Jetty.

And I learned that eXist actually supports both XML and binary data, which was just what we needed. With eXist, we also get XQuery support and various interfaces to the data. In our case, this is less of an immediate concern, given Scala’s XML support and for expressions are a bit like built-in XQuery capabilities. For instance, a query on XML that is equivalent to the ScalaQuery from above could look like this:

val bonifaci = for (page <- xml\"page"; word <- page\"word";
  if (word\"@original").text == "Bonifaci") yield (page, word)

This is not only about as concise as the query above, but also allows to express the hierarchical nature of our data in the query (‘each word in the page’), instead of having to map the relational representation (‘all words with a certain page ID’).

As we already deserialize the XML to page objects, what we actually do is query on these. For switching the serialization from entries in a zip file to the eXist DB and allow these queries, the only conceptual change was to store the XML and image files in the DB instead of using a File object, which allowed a really smooth transition.

And with Scala’s rich semantics and XML support, our DB wrapper in Scala can be very simple and precise about what it offers in its API, namely XML documents for a collection ID (if found in the DB):

val xmls:Option[List[Elem]] = Db.xml(collection)

Or binary data:

val imgs:Option[List[Array[Byte]]] = Db.bin(collection)

The elements provided by the DB in this way can be passed to the original deserialization method of Page:

val pages:List[Page] = for(page <- Db.xml(collection))
  yield Page.fromXml(page)

Given this, we can now use a plain Scala for expression on the deserialized objects to query our data like this:

val bonifaci = for (page <- pages; word <- page.words;
  if word.original == "Bonifaci") yield (page, word)

At this point we have replaced the file storage with the DB, but are still creating the XML manually, using Scala’s XML literals. To avoid any duplication (each class parameter or field is represented again in the serialization logic), and basically eliminate all direct XML manipulation, we could use an XML binding library like scalaxb, JAXB-RI or MOXy.

On the other hand, the type safety of the Scala XML serialization code makes the duplication feel much less dangerous than traditional, string-based XML serialization (which can break easily unnoticed by the compiler). And being about as concise as some JAXB annotations and marshalling code would be, the disadvantages seem almost entirely theoretical, but we’ll see – swapping the serialization logic should be as easy as swapping the storage implementation was.

When we last left our erstwhile travelers (that would be all of you) they were surfing the quantum wave on their way to a future refactoring of their past to allow them to simultaneously feel proud of their work and embarrassed that they were following some guy who is making it all up as he [...]

There was a long time no update from my side. Mostly because of my new full time project. Another reason was - I've played a bit with different Linux distributions.

Finally I've decided to move to Mint (based on Ubuntu). This is a great distribution which is far easier to manage as Windows XP, even for complete beginners. I've also tried Windows 7, but it was not really better then XP except that it can address now all 8 GB of RAM I have in my PC. From the administration point of view, I found Mint (Ubuntu) much easier.

So why this post? After switching to Ubuntu, first think I've stumbled upon was the HUGE toolbar size used by Eclipse. Horrible. So I had to tweak my GTK themes and also one of my plugins, to get this toolbar's to the proper dimensions. May be more about this later (I've patched one of Murrine themes), but as a result, I've released a new 1.5.6 version of the Extended VS Presentation plugin. Additionally it has a bugfix for the maximize/minimize actions which were not properly working on Linux in some cases.

Enjoy.

There are rumors that Xtext does only have rudimentary support for language libraries or language reuse and does not allow to create 'advanced stuff'. And it is actually true, that Xtext has only first class support for extending only one other language. But with some creativity and customizing, it is easily possible to create really nice editors for intermixed languages. I've produced a small screencast that demonstrates how an editor for template proposals (read: a template language) may look like when it's aware of your target syntax.



Besides the smart editor for template proposals there is another interesting feature in this screencast: As template proposals are usually edited on a preference page, I implemented a small prototype that shows how a form field may leverage the features of a full blown Xtext editor.

Both prototypic implementations are only based on Xtext 1.0 APIs and not yet publicly available. But I'ld assume that at least parts of them will be moved into the Xtext Indigo stream. Stay tuned!

IDE Innovation

Every now and then some folks report that the IDE they’re developing now supports this or that cool new feature. Sometimes I envy them for such progress - but more often than not I end up realizing that the OTDT already has that feature or something very similar. Is that just my personal bias (which certainly I have) or are we cheating in some way, or what?

There’s a little detail in the design of the OTDT that turns out to make such a difference as normally can only achieved by cheating: by the way how the OTDT extends and adapts the JDT it is like saying we’re starting the race not at the line saying “START” but at the other one saying “FINISH” and run on from there. While many projects define “JDT-like user experience” as their long-term goal, the OTDT basically has this since the first release. How come? The OTDT basically is the JDT, with adaptations.

There’s a fine point in the word basically. To tell the truth, every feature that the JDT supports for Java development is not automatically fully available in the OTDT for OT/J development. In fact most JDT features need adaptation to provide equal convenience for OT/J development. It’s just that all these adaptations can be brought into the system very very easily - thanks to the self-application of OT/Equinox. And now, here is actually an example of a JDT feature that lacked OT/J support - until yesterday:

Change Method Signature Refactoring

If you refactor mercilessly the “Change Method Signature” refactoring is certainly one of your friends. Add/rename/remove/reshuffle parameters of a method without (too easily) breaking existing code, cool. It knows about the connections from method invocation to method declaration and about overriding. That’s good enough for Java, but not good enough for OT/J since OT/J introduces method bindings (”callout” and “callin”) that create a wiring between methods of different objects. Obviously, if one of the methods being wired changes its signature so must the method binding.

Technically, the JDT implementation of that refactoring bailed out when it asked a parameter/argument for its parent in the AST and found neither a method declaration nor a method invocation. The JDT refactoring does not know about OT/J method bindings, so it just failed to update those.

After a little of coding this is what happens now when you apply “Change Method Signature” on a piece of OT/J code. Assume you have a plain Java class:

public class BaseClass {
	public void bm(int i, boolean b) {
 
	}
	void other() {
		bm(3, false);
	}
}

and a TeamClass whose contained RoleClass is bound to BaseClass:

1
2
3
4
5
6
7
8
9
10

public team class TeamClass {
	protected class RoleClass playedBy BaseClass {
 
		void rm(int i2, boolean b2) <- after void bm(int i, boolean b);
 
		private void rm(int i2, boolean b2) {
			System.out.println((b2?i2:-i2));
		}
	}
}

Here the right-hand side of the callin binding in line 4 refers to the normal method bm(int,boolean) defined in BaseClass.

What happens if you start messing around with the signature of bm?
Like:

I.e., we are adding a parameter str and also change the order of parameters (from i,b to b,str,i). I don’t have to tell you what this refactoring does to BaseClass, but here’s the preview of those changes affecting TeamClass:


(sorry the screenshot is a bit wide, you may have to click to really see).

The preview shows that the refactoring will do three things:

1. Update the right-hand side of the method binding.
2. Add a parameter mapping (the part starting with “with“) to ensure that the role method rm receives the arguments it needs, the way it needs them.
3. Do not update any part of the role implementation, because that’s what the parameter mapping is for: shield the role implementation from any outside changes.

Some words on these parameter mappings: each element like “b2 <- b” feeds a value from the right-hand side (representing things at the baseclass side) into the parameter at the left-hand side (representing the role). The list of parameter mappings is not ordered, which means further swapping of base side parameters requires no further action. And indeed the current implementation of the refactoring does not attempt to adjust an existing parameter mapping (which might be a quite complex task). If adjustments are required which the refactoring cannot perform automatically, it will inform the user that perhaps a parameter mapping may need manual adjustment.

The refactoring applies no AI to guess what the intended solution should look like, but it performs a number of obvious adaptations and gives note when these adaptations may not suffice and manual cleanup may be needed.

Implementation

Those who have read previous posts may (almost) know the kind of statistics that follows:

• 299 LOC implementation
• 315 LOC testcode
• 170 LOC testdata

I should really show one of these OT/J based implementation, one of these days. For this post I will just give you an Outline, literally:

Role class Processor is bound to the JDT’s ChangeSignatureProcessor, and the nested roles OccurrenceUpdate and MethodSpecUpdate are bound to two inner classes of ChangeSignatureProcessor, which shows how even class nesting at the base level can be mapped to the team & role level. Instances of the innermost roles will only ever come into being, if a Processor role has detected that it needs to work in order to handle OT/J specific code. Inside each role - apart from regular fields and methods - you see those green arrow-things, denoting method bindings between a role and its base. The highlighted binding to createOccurrenceUpdate is actually the initial entry into the logic of this module. Further down you see how the base behavior reshuffleElements is intercepted to additionally add parameter mappings if needed (and yes, I’m hiding the details of role MethodSpecUpdate, but there are no secrets inside, I just more methods and more method bindings).

Voilà, we indeed have a new refactoring for OT/J. I’ve been planning this one for a while but in the end it took me little more than a day

Another month, another Saros release. This time around it consists mostly of bugfixes…

… but be advised. There are now a couple of dozen youngling programmers busying away at Saros code like worker bees for the next few weeks.

Expect a bumper crop of fixes and features in September!

Hi there,

In the context of an IResourceChangeListener I need to modify a given preference file in the workspace.  Because of “Note that during resource change event notification, further changes to resources may be disallowed.” the only solution to perform this change is to delay it on a future event (5 seconds later, on the next access to the file to be modified, on the next selection event, etc ..)

I would be interested to know how do you handle such situation ?

If you would like to search in eclipse forum, here is a quick form which may help you.

Most Active Projects

New Projects

I have the pleasure to present Xtext in two of the most beautiful european cities within the next two weeks.

I have been checking out developer.force.com this week and it is a pretty extensive cloud based solution for developing, deploying, and using applications in the cloud.  I checked out their Eclipse based development videos and the development environment looks pretty comprehensive.  I would like to hear if anyone who reads this blog has any real experiences they would like to share about it.  I am also interested to hear how many of my readers have real exposure to SalesForce.com.

If you use SalesForce.com in any manner, application use, develop for, deploy on, integrate with or any of the above please take some time to post your answer below and possibly a comment on your experiences.

If you are a Lotus customer I would like to hear how you integrate your XPages, Domino or Notes applications with SalesForce.com.

Thanks in advance!

Today I vetoed the nomination of five potential committers. This is something I really disliked and hated doing but I believe I had to: all five nominated persons have reported a few bugs but have not (yet) contributed a single patch. They have been nominated because the company they work for is going to contribute a cool feature to the WTP Incubator project and these people are supposed to maintain the code. Unfortunately, the contribution is still outstanding and the code is not yet Open Source.

What do you think? Should the Eclipse Process be changed so that everyone who likes to contribute and signs the Member Committer Agreement automatically becomes a committer? We have fewer than 500 about 1,000 [see Wayne’s comment below] Eclipse committers and probably in every Eclipse project there is a need for more contributors and committers. To lower the hurdle of becoming a committer also means lowering the attractiveness of being one of a select group of Eclipse committers and this may have the opposite effect: less instead of more active committers.

Update: After the code had been made public as an attachment in Eclipse Bugzilla I restarted the nomination. The code really looks good and I’m happy that WTP Incubator will grow by an interesting feature and by five committers who deserve this status. Looking back, I think that when a nomination comes along with a contribution we should always demand that the contribution is made public before or at the very beginning of the nomination process (if it is not already Open Source). Unlike me, you should not only ask for it but also veto as soon as possible so that it is clear that this has to be fixed before the nomination ends (you can then change your vote from -1 to +1 or 0).

I learned from Steffen Pingel and Ekkehard Gentz that Mylyn has the ability to save local tasks outside the workspace. This is hidden under advanced in the Preferences.

This allows you to put your local tasks outside your workspace and versionize them with git. This way you can use git to move your local tasks between machines. I really like this as I frequently use different machines and now I can not only share source code betwee them but also my mylyn taslks.

As Steffen told me, simultanous access to the Mylyn tasks might cause task corruption but I don’t think that is an issue for me as Git takes care of conflicts and I do not have two machines writing to the same local file.

Fun times with Git and Mylyn!

If you could build the perfect Android tablet, what would it look like? That’s the question I asked myself last week when I started this series. The number 1 feature was, well, you can go read about it yourself if you missed it. Now it’s time for the second most important feature:

#2: Capacitive touch screen with smooth 10+ finger multi-touch

Recently I had the distinct displeasure of trying out an el-cheapo Android tablet from Augen that came with a resistive screen and, of all things, a stylus. Don’t let anybody fool you. Resistive screens are bad. Very bad. I’m serious about this. I don’t care how cheap they are — you should avoid them at all costs. Do. Not. Buy.

Now that that’s out of the way, let’s talk about multi-touch. For the first couple of years of Android history, Android phones were single-touch. Point, tap, drag, and that was about it. iPhones supported multi-touch gestures like pinch zoom, and Android fans suffered the indignity of having the competition do something better than their baby. Well, at least Android had cut-n-paste, so there.

About the time iPhone finally got cut-n-paste, Android got multi-touch. Sort of. Unfortunately the first implementation on the Nexus One was pretty bad. Aside from jerky low-res registration of finger movements, it often got the coordinates of tracked fingers confused. Partly this was because of limited digitizer hardware used by HTC, and partly this was because of, ahem, idiosyncrasies in the software stack. You can read more about it in my multi-touch series and in various discussion groups and bug reports.

Anyhoo, newer phones, especially the Droid Sholes and successors from Motorola, included a better digitizer that fixed some, but not all, of the problems. Still, a fundamental issue remains: At its best, all Android devices on the market as I write this are limited to only tracking 2 fingers at once.

So sure, you can do pinch and zoom but you can forget about 3 finger swipes and more elaborate gestures that people have thought up. More importantly, only having 2 fingers rules out a whole class of applications like guitar and piano applications, synth controllers, chorded keyboards, and games that two or more people can play. Especially, say, on a larger screen, like a tablet.

A tablet practically begs for lots of fingers to touch it. I own an iPad, and one of my favorite programs there is called Magic Piano by Sonic Mule. I can use all 10 fingers at once to play any music that I could play on a real piano. Unfortunately, I can’t play a duet with a friend on the same iPad because it maxes out at 10 or 11 fingers. Any more than that, and the touch screen simply doesn’t register the touches.

Are you hearing this, HTC, Motorola, and Notion Ink? Paying attention, Asus and Samsung? To make the perfect tablet, please bring on that silky smooth capacitive goodness with support for *at least* 10 fingers caressing the screen at once, starting at the hardware level and going all the way through the Android software stack. And if you can, make it better than the iPad by supporting more than 10 fingers at once. My fledgling musical career depends on it.

What would you build into *your* perfect Android tablet? Share your thoughts in the comment area below. And check back next week to find out what’s next on my list.

UPDATE: an update site including Jin’s GSoC work is now available.

I was lucky enough to be the mentor on a Scala IDE for Eclipse project which was selected for this year’s Google Summer of Code. Jin Mingjian was the student for this project, and it’s been wonderful to work with him over the last few months.

Jin completed his Doctoral degree at the Institute of Electrical Engineering in the Chinese Academy of Sciences this summer … having to deal with his PhD defence at the same time as the GSoC project was quite a tall order!

He had this to say about himself and about his project …

I have been involved with the Eclipse community for a long time. When I discovered Scala this year, I realized that it was the language that I need. The openness of Scala struck me, as much as the technical merits of the language itself. The Scala IDE community combines two great open source communities and this summer’s GSoC gave me the opportunity to work on it. I like being part of this community. Join us to help to create great Scala tools!

Now that the GSoC ‘pencils down’ date has arrived, it is time to report to the community about the achievements of my Scala IDE project. The goal of this project is to provide Advanced Semantic Tools for the Scala IDE for Eclipse.

First, I am very appreciative for lots of helpful suggestions, advice and encouragement from my mentor Miles Sabin and other guys in the community. Without their help, it would not have been possible to finish this project.

There is a wiki page on the Scala IDE project site which explains some aspects of the features. Let me introduce them by starting with an example code snippet,

object String2Int {
  val a = "1";
  var b: java.lang.String = "3";
  implicit val somewords = new SomeWords("yeah!")

  implicit def string2Int(s: String) = {
    ((s.toInt)+1)
  }

  def main(args:Array[String]) {
    printInt(string2Int("3"))
    printInt(a+b)
    printIntWithSomeWords("5")(new SomeWords("..."))
    printIntWithSomeWords(2)

    val map = Map( 1 ->"one",2->"two")
  }

  def printInt(a:Int) {
    println(a)
  }

  def printIntWithSomeWords(a: Int)(implicit sw: SomeWords) {
    println(a)
    println(sw.words)
  }

  class SomeWords(val words: String)
}

This code stems from an example in Programming in Scala. But I modified it to be “more implicit”.

When you open the editor, all the places where implicit conversions and implicit parameters occur (not the implicit definitions themselves) have been highlighted, as follows,

Perhaps you don’t like the default green squiggly underlines as the visual indicator of implicit occurrences? Then you can customize the highlight style via Windows -> Preferences -> Scala -> Editor -> Syntax Coloring as follows,

You can hide the highlighting by clearing the checkboxes and setting the underline style to “none”. In future we will add an enable/disable check box to simplify this process.

Along with the visual annotation for implicits, we provide automation around the annotation, known in Eclipse terminology as “quick assists”. The default shortcut for quick assist is “Ctrl+1″. The following screenshot shows the quick assist for an implicit conversion,

After applying this quick assist we get the explicit version of above implicit conversion,

The following screenshot shows the quick assist for implicit parameters,

After the applying the quick assist, we see the implicit arguments defined in the scope explicitly inlined as follows,

One of Scala’s important features is support for type inference. With type inference we are not forced to write many tedious type decorations. However, Scala is a strongly type language and in some contexts it is better to declare the type explicitly, for example method return types.

So we have added functionality which provides explicit type completion, activated automatically by typing “:”. The current implementation is limited to val and method definitions for which the type can be inferred.

The following screenshot shows that I want to add an explicit type for val map. So I type the “:” after the map identifier. Then I get the inferred type quick assist here,

When I press Enter, we see the following,

Currently the explicit type is a little long. In future we will allow the qualified part to be moved to the import section.

It is a best practice to add explicit return types for methods (other than for methods which return Unit type). And sometimes you forget to add the “=” when defining a method. This makes the whole method return Unit unfortunately. With our new functionality and that best practice quick assist, you can find and fix this kind of mistake easily. For example, suppose you wanted to add the type for the method by “:” auto-completion. But you find that the proposed type is Unit. Then you will realize that you missed the “=”,

Correct it and add the right type again as follows,

Adding explicit types for val and method definition is a piece of cake now. In future we will improve explicit type completion to propose types from the classpath if the exact type cannot be inferred.

What do you think about these new features? A build/update site of the GSoC branch will be available shortly and any feedback will be appreciated. When the features has been proven stable, we will merge them into the main distribution. Then everyone can try them out!

I've been working hard these past weeks in my evil secret lair. Well, maybe not so secret, given that the results are, in true open source fashion, open: 323050. But it's definitely evil: among my tasks this week has been rejecting 6 out of every 7 Eclipse Summit Europe modeling submissions. I'm sure no one will take it personally and I'll remain ever so popular. Not! In any case, I'm taking to the clouds today!


That's right, I'm headed for Google's headquarters, with my brand new passport anxiously awaiting its first stamp of approval. (Did you know that a trip through the washing machine will launder all evidence of ever having been to the states?) It's Eclipse Day at the Googleplex where I'll be unveiling my master plan: world domination for Eclipse Modeling. Resistance is futile. Expect to be assimilated soon.

After working on the Riena framework for nearly a year now, together with some colleagues I am challanged to use Riena to build a small Client Server Application for our team. I never thought what a refreshing eye opener this can be from time to time. It is one thing to sit in your closed framework environment where everything makes total sense, but suddenly sitting on the other side of the table often makes you want more.

The requirement

So while designing the structure for our application we came across a requirement for Riena: closable SubModules. Until then, only Modules and ModuleGroups were closable via the UI, but as soon as a SubModule was added to the navigation tree it was there until the parent Module was closed or until it was removed programmatically in another way.

The ideas

The first step was to think about solutions in our own application, so we put a close button on every view that should be closable. Now that was ugly! But it was the fastest way to get the functionality. Okay, now that we had the functionality we had some time to think about solutions that would flowlessly fit into the Riena design:

Idea No. 1

1. Put the close button in the navigation tree and let in only show up when the mouse is hovering over the node in the tree. This would have the advantage that it fits into Rienas design quite well, since the close buttons for the Modules are in the navigation as well. But the disadvantage was that we only have limited resources to work on our application and this solution would have taken quite a long time. There had to be an easier way.

Idea No. 3

2. Put the close button underneath the title bar. This would have been in the top right corner of the SubModuleView. But after some discussion this idea was dropped because it would have been a large change for all existing SubModuleViews now having to share the space with a little button.

3. Put the close button in the title bar of the SubModule. This is similar to the close buttons in the Microsoft Office Suite, where a second button under the “application close button” closes only the document visible at the time. It isn’t as flawless as Idea No. 1, but very easy to accomplish because the SubModuleTitleBar renderer extends the renderer of all Modules. Yeah, that was nice.

The solution

As you probably already guessed, solution No. 3 was implemented. All we had to do was to give the SubModuleNode the attribute “closable” and move some code around to make the close button show up in the title bar of the SubModuleView. Perhaps in the future we can also implement solution No. 1 and let the application programmer choose which one to use as we did with the error decoration.

What do you think? Would you use closable SubModules? Which solution would you have preferred?

Headless building Update Site

There is no easy way to achieve this. There have been some discussions in past and the Build and Test Automation article too touched it in brief. But its all hacky. I tried various stuff but the closest I could get was build features and plug-ins using (mentioned in) a site.xml and generating the metadata for them. The site.xml can be placed with them manually but I could not find a way to (automatically) update the site.xml with the feature and plug-ins build qualifiers. (There are always hacks like having a dummy site.xml and do a find-replace in it. Or write a custom ant task that emits XML for ste.xml - none of the hack is very maintainable or scalable)

After more investigation I realized may be I was trying to solve the wrong problem. We really don't need the update site (not if you are using Eclipse 3.4 or later). A p2 repository is not only easy to generate but is also the recommended way of distributing features and plug-ins.

Headless building a p2 repository

Now a p2 repo can be generated either from a bunch of features and plug-ins or directly from a product configuration. Both explained in Eclipse help. We will here take a product configuration and build a p2 repository for it. The setup will be same as discussed before. However this time, we will copy all the files from /org.eclipse.pde.build/templates/headless-build folder to our build configuration folder (build\buildConfiguration). Thus, the build structure will now looks like this

<buildConfigurationDirectory>
       allElements.xml
       build.properties
       customAssembly.xml
       customTargets.xml
<buildDirectory>
       plugins/
              com.example.helloworld
              com.example.product
                     example.product
       features/
              com.example.helloworld.feature

<target name="post.gather.bin.parts">
 <p2.publish.featuresAndBundles
  repository="file:/${buildDirectory}/repository"
  source="${buildDirectory}/tmp/${archivePrefix}" 
  compress="true"
 >
 </p2.publish.featuresAndBundles>
</target>       

java -jar c:\eclipse\plugins\org.eclipse.equinox.launcher_1.1.0.v20100507.jar -application org.eclipse.ant.core.antRunner -buildfile c:\eclipse\plugins\org.eclipse.pde.build_3.6.0.v20100603\scripts\productBuild\productBuild.xml -Dbuilder=c:\build\buildConfiguration

A few months ago Chris started a discussion about Eclipse and Academia and how Eclipse could support research projects to participate in the Eclipse Ecosystem. Furthermore, the upcoming Eclipse Magazin will also contribute to this discussion. However, the discussion how Eclipse could help and benefit from research projects is dangling. With this post, I would like to pick pick up Chris' blog post and present an idea how eclipse and research community could get together to create something (I think) very fancy...

In my last posts, I presented our preliminary work on improving IDEs leveraging the hidden knowledge available in example code that uses other APIs (visit code-recommenders@eclipselabs and the official project homepage  for more details). A few weeks ago we wrote down our vision of how future IDEs should work---which you can find and comment below. This post is basically the preprint version of this paper (which got accepted today at the Working Conference "Future of Software Engieering Research") and we would love to get the your feedback to the vision we present here. As said above, we did a lot of work to get where we are today and the question is now: Should we continue to let the visions below come reality? Clearly, this vision will only work with a very vital community around the project - which I think can be found nowhere else than at Eclipse. But how do you feel about that? Just read the vision and tell us about your opinion (yes, I know it's longer than a standard post. Sorry for that but I hope it's worth reading ;-) ).

IDE 2.0: Collective Intelligence in Software Development 

Under the right circumstances, groups are remarkably intelligent and are often better than the smartest person in them.

Figure 1: Our vision: in the future, IDEs will be linked through global knowledge bases

If you have a lot of projects in your Eclipse workspace you should check out the Dynamic Working Sets plug-in.

It allows you to define working sets based on a regular expression. If a project name matches the regex it will be included in the working set.

It sure beats adding new projects to existing working sets all the time. Really handy to keep your workspace organized.

Last week Wim Jongman bloged about the Nebula Oscilloscope widget. It’s just an awesome widget for monitoring activity. See Wim’s post to form an opinion yourself.

So, for me as a RAP developer, the first question I always ask myself when seeing such a cool thing is: “Will it run on RAP?”. I followed the steps Wim described to get the Oscilloscope running, changed the target to RAP, commented out one line of code and started the application. You can see the result in the screencast below.

I think the result is just awesome. It runs very smooth with almost no lags. For all of you who don’t know it yet, this is possible because we implemented the GC and published it with RAP 1.3. The updates from the server are realized via the UICallback mechanism of RAP. I think this video shows that, in the meantime, RAP became a very sophisticated technology. We are all looking forward to seeing a lot more cool things like this working with RAP.

Parsing simple XML-like, structural languages with Xtext is a no-brainer. However, parsing nested expressions is often considered a bit more complicated. This is because they are more complicated due to their recursive nature and also because with Xtext you have to avoid left recursive parser rules. As the underlying parser (generated by Antlr) uses a top-down approach it would recurse endlessly if you had a left recursive grammar.

Let's have a look at parsing a simple arithmetic expression:

2 + 20 * 2

Expression :
 Expression '+' Expression |
 Expression '-' Expression |
 INT;

Addition :
 Multiplication ('+' Multiplication)*;

Multiplication:
 NumberLiteral ('*' NumberLiteral)*;

NumberLiteral:
 INT;

Addition :
 Multiplication ('+' Multiplication)*;

Multiplication:
 Primary ('*' Primary)*;

Primary :
 NumberLiteral |
 '(' Addition ')';

NumberLiteral:
 INT;

NumberLiteral : … ;

NumberLiteral returns NumberLiteral : …. ;

Addition returns Expression:
 Multiplication ('+' Multiplication)*;

Multiplication returns Expression:
 Primary ('*' Primary)*;

Primary returns Expression:
 NumberLiteral |
 '(' Addition ')';

NumberLiteral:
 INT;

Addition returns Expression:
 Multiplication ({Addition.left=current} '+' right=Multiplication)*;

Multiplication returns Expression:
 Primary ({Multiplication.left=current} '*' right=Primary)*;

Primary returns Expression:
 NumberLiteral |
 '(' Addition ')';

NumberLiteral:
 value=INT;

As soon as the parser hits an assignment it checks whether an AST node for the current rule was already created. If not it will create one based on the return type, which is NumberLiteral. The Xtext generator will have created an EClass 'NumberLiteral' before which can now be instantiated. That type will also have a property called value of type Integer, which will get the value '1' set. This is what the Java equivalent would look like:

// value=INT
if (current == null)
 current = new NumberLiteral();
current.setValue(ruleINT());
...

Now that the rule has been completed the created EObject is returned to the calling rule Primary, which in turn returns the object unchanged to its own caller. Within Multiplication the call to Primary has been successfully parsed and returned an instance of NumberLiteral. The second part of the rule is a so called group (everything within the parenthesis). The asterisk behind the closing parenthesis states that this part can be consumed zero or more times. The first token to consume in this part is the multiplication operator '*'. Unfortunately in the current situation the next token to consume is the plus operator '+', so the group is not consumed at all and the rule returns what they got from the unassigned rule call (the NumberLiteral) .

In rule Addition there's a similar group but this time it expects the correct operator so the parser goes into the group.
The first element in the group is a so called action. As Xtext grammars are highly declarative and bi-directional it is not a good idea to allow arbitrary expression within actions as it is usually the case with other parser generators. Instead we only support two kinds of actions. This one will create a new instance of type Addition and assign what was the to be returned object to the feature left. In Java this would have been something like:

// Multiplication rule call
current = ruleMultiplication();

// {Addition.left=current}
Addition temp = new Addition();
temp.setLeft(current);
current = temp;
...

As a result the rule would now return an instance of Addition which has a NumberLiteral set to its property left. Next up the parser consumes the '+' operator. We do not store the operator in the AST because we have an explicit Addition type, which implicitly contains this information.
The assignment ('right=Multiplication') calls Multiplication another time and assigns the returned object (a NumberLiteral of value=20) to the property named right.

If we now had an additional plus operation '+' (e.g. 1 + 2 + 3) the group would match another time and create another instance of Addition. But we don't and therefore the rule is completed and returns the created instance of Addition to its caller which was the second alternative in Primary. Now the closing parenthesis is matched and consumed and the stack is reduced once more.

We are now in rule Multiplication and have the multiplication operator '*' on the look ahead. The parser goes into the group and applies the action. Finally it calls the Primary rule gets another instance of NumberLiteral (value=2), assigns it as the 'right' operand of the Multiplication and returns the Multiplication to Addition which in turn returns the very same object as there's nothing left to parse.

The resulting AST looks like this:


The following video tries to explain what you just have read. The grammar is slightly different, but I'm sure this won't be problem for you ;-).

Addition returns Expression:
 Multiplication ({Addition.left=current} '+' right=Multiplication)*;

Addition returns Expression:
 Multiplication ({Addition.left=current} '+' right=Addition)?;

Addition returns Expression:
 Multiplication ({Addition.left=current} '+' right=Multiplication)?;

I’ve never been to Eclipse Summit Europe.  I’m told it’s because there’s not enough beer in Germany to accommodate my lavish consumption.

Regardless, I’ve started working with the conference organizers towards providing better/more Wifi coverage at the conference in a manner that would resemble what is provided at EclipseCon.

This is where we play the game of estimating how much Internet bandwidth you’ll use up, double the number, then double it again, and then have our calculations be demonstrably wrong once the conference is in full swing.  But that’s part of the fun!

From the title you might be thinking I was going to talk about how we can encourage new-comers to get involved with and contribute to Eclipse, blah blah blah. But you'd be wrong. I'm actually going to talk about a thingie that shows up on your install when you first pull off the shiny shrink wrap of an Eclipse RCP / SDK Application / Product / Whatever.. Rather than get into the details -- the Eclipse documentation is quite good (as one hopes it would be!), and there are a number of nice tutorials on it -- I'd like to discuss more generally what Eclipse offers, how it fits into the overall picture and discuss how it might be improved. There may be a few useful technical tidbits buried in here somewhere..

I wrote most of this post back in February but have been too busy with other things to ever get back to it. But this bugzilla I received last night made me think that I wasn't the only one that has had trouble grasping the overall logic of the Eclipse User Assistance system, so I decided to spend the time to resurrect it. I hope it gets a little discussion going.

Drawing Users In

Help!!

Welcome!

Cheat Sheets

• Parent cheat sheet name and id


• Parent cheat sheet file name


• Group name


• Child cheat sheet names


• Plug-in id, name and client link.

Connecting it all Together

Calling commands from Help

public class ExecuteJavaModelAction implements ILiveHelpAction {

    String javaPath;

    /**
     * Launch the Escap model.
     * 
     * @see java.lang.Runnable#run()
     */
    public void run() {
        IPath path = new Path(javaPath);
        EclipseEscapeRunner eclipseRunner = new EclipseEscapeRunner();
        IProject javaProject = ResourcesPlugin.getWorkspace().getRoot().getProject(path.segment(0));
        IPath fullPath = path.removeFirstSegments(1);
        try {
            javaProject.open(null);
            eclipseRunner.open(javaProject, fullPath.toPortableString(), fullPath.lastSegment());
        } catch (CoreException e) {
            throw new RuntimeException(e);
        }
    }

    /**
     * Define the Java pah to the model node.
     * 
     * @param data
     * @see org.eclipse.help.ILiveHelpAction#setInitializationString(java.lang.String)
     */
    public void setInitializationString(String data) {
        javaPath = data;
    }

<a href='javascript:liveAction("org.eclipse.amp.escape.ide", "org.eclipse.amp.escape.help.ExecuteJavaModelAction",
 "org.ascape.escape.models.brook/edu.brook.sugarscape.GAS_II_1")'>

Calling Cheatsheets from Help

Please follow this <a href='javascript:liveAction("org.eclipse.ui.cheatsheets", "org.eclipse.ui.cheatsheets.OpenCheatSheetFromHelpAction",
"org.eclipse.amp.escape.loadProjects")'>cheatsheet</a>.

Hey, I still can't open this can!

As promised in the last post, here is a new updated widget for the attachment viewer. You can download the latest source files from the OpenNTF project.  If you want to learn how to install this into Notes 8.5.1 and above check out the video I posted to show how to do that.

Here is a summary of the support and you can also watch a video here or below:

- ODF thumbnail support added, .odp, .odt, .docx, .dotx, .docm, .dotm, .xlsx, .xlsm, .xltx, .xltm, .pptx, .pptm, .potx
- Modified Zip file to limit embedded text files to show only first 20K
- JAR file support – extended the ZIP provider to include Jar files
- New Text File support – .mf, .properties

• customTargets,xml
• allElements.xml
• customAssembly.xml

If you are using Eclipse you properly using Mylyn. I recently got a new machine and wanted to migrate my local Mylyn tasks from one computer to another.

Local tasks stored in your workspace in .metadata/mylyn/tasks.xml.zip. The context for local tasks stored in .metadata/.mylyn/contexts… look for files labeled local-X.xml.zip, these have the context. You can back up the entire Mylyn data directory and put it into the same place on your new computer.

Worked well for me!

Thanks to David Shepherd for the tip via twitter.

Almost every week, I hear about new and existing Java libraries or frameworks becoming “OSGi Compliant”. This makes me happy as it indicates the traction that OSGi is getting as a platform. The only problem is that “OSGi Compliant” could mean almost anything… and therefore it means precisely nothing.

For example, many libraries can be easily used in OSGi even if they don’t provide an OSGi descriptor (i.e., a MANIFEST.MF containing Bundle-SymbolicName etc.), so long as they steer clear of certain problematic coding patterns such as classpath scanning, unconstrained use of Class.forName() and so on. Such libraries could reasonably be termed “compliant”. But another framework may have been deeply integrated into OSGi so that it can make use of services, receive configuration through Config Admin, and so on.

It seems that we need a vocabulary that will help us distinguish these two cases, and those in between. We need to define, at least informally, some kind of Beaufort Scale for levels of OSGi compliance (if you’re feeling uncharitable towards OSGi you may prefer to call it a Schmidt Pain Index).

The purpose of the exercise would certainly not be to admonish authors of libraries that rate near the bottom of the scale, nor to congratulate those at the top. Rather, it would help authors to communicate the depth of their support for OSGi in a more precise way, and it would help the OSGi community communicate to library authors how they can make their products more useful to us.

To get the ball rolling, here are my initial thoughts. I do this merely to invite feedback rather than to attempt to impose my own classification.

For many libraries, there is no need to go any higher than level 1. The higher levels are applicable to frameworks, which are more complex and may feature extensibility through plug-ins, custom configuration, logging, etc. Obviously I would like to see all libraries reach at least level 1, but the OSGi community needs to do more to make this easier.

A key concern for many frameworks as they seek to rise this pyramid is to remain usable outside OSGi, which is a goal I support. There appears to be very little information available on how to develop frameworks that are able to take advantage of OSGi without introducing a hard dependency on it. This is something I hope to remedy in future posts.

What do you think of this taxonomy? Is it useful, or a waste of time? Should there more levels, or fewer? Please comment below, or link to your own blog.

UPDATE Christian Baranowski blogged some thoughts about independent verification of bundle compliance. That’s a great idea, but my initial goal is less ambitious, i.e. simply to allow library authors to assert something meaningful about their level of OSGi compliance. I think that is a prerequisite before looking to verify those assertions.

UPDATE 2 BJ makes some excellent points in the comments below, which I entirely agree with. Be sure to scroll down and take a look.

Max Lifshin, an Android developer living in Russia, says his Tap Snake program is not a Trojan or virus, despite a warning from security software maker Symantec last week. Lifshin has been vilified in the press for releasing the program, which was intended for parents to track their children’s whereabouts. Reached by ZDNet for comment, Lifshin insisted that his motivations were innocent:

The app is no more malicious than a motion detection camera - everything depends on the user’s intentions. It gives all the proper warnings and requires a set up, a conscious action, to report location. It can be easily used by mothers worrying about their kids’ whereabouts. In fact, I suspect the majority of users were indeed the mothers.

For the program to work, the parent or guardian downloads and installs the innocuous looking game on their kid’s phone. During the installation process, Android asks for permission to access location information and to send and receive information to the Internet. After accepting these terms, the parent must open up a menu option and activate the tracking service with a unique key. Then they give the phone back to their child. From that point on, the game will occasionally upload its location to a server, where only somebody with the key can view it. Lifshin says:

The app is not really very different from Google’s Latitude. As any technology product, it can be put to either noble or malicious ends.

The game can be uninstalled at any time. The program run by the parent to view location information is called GPS Spy. The Market description for GPS Spy openly explained how all this works, saying:

Download and install the free Tap Snake game from the Market to the phone you want to spy on. Press MENU and register the Snake with the service. Use the GPS Spy app on your phone with the same email/code to track the location of the other phone.

However, the description of the Tap Snake game did not say anything about tracking, presumably so your child could look up the game for updates or reviews and be none the wiser. Until recently, Tap Snake was a free download and GPS Spy was $4.99. After the news came out, Google removed both apps from the Market. According to Lifshin,

What’s sad is that these “whistle blowers” have prompted Google to suspend the app and thus deprived me of income. They unfairly classified this app as a Trojan and portrayed me as a villain, a malicious Russian developer working in the shadows.

What do you think: is this a dangerous Trojan or a useful safety device for parents? Was Google right to ban it? Speak up in the Talkback section below.

Any resemblance to real applications, living or dead, is purely coincidental…

My previous blog, described a business problem based on a case study by Intalio and one of its business partners. Before I go any further I should probably clarify the purpose of this blog, lest I be sued for misrepresentation.

DISCLAIMER

The case study and accompanying implementation presented here, while it may make references to actual implementations and case studies published by Intalio and/or its business partners, is entirely my own work and does not in any way intend to represent any actual original work performed by any business entity, anywhere on this planet or any other time/space continuum.

The reason for this blog is to promote BPEL technology by teaching web service integration concepts based on real-world implementations, using BPEL as the orchestration tool, and not to rip off other people’s work. The actual implementations presented here are based solely on my observations, Gedankenexperiments and reverse-engineering of these real-world business problems and their solutions.

I do not claim to be a Subject Matter Expert in the area of airline reservation systems, and the existence of any supporting systems described below is pure speculation on my part (based on life experience, internet searches and just plain pulling stuff out of thin air to suit my needs). The actual availability, behaviour and capabilities of these systems may be much different than postulated here. As stated, the focus is on BPEL and web service orchestration, and any of these supporting services and resources will be “stubbed in” wherever necessary to present a working end-to-end solution.

There, I think that just about covers it. Now let’s have some fun…

Identifying the Resources

As mentioned in the first instalment of this series, the primary design goal is to use open source software whenever possible and resort to rolling our own only when necessary. This means that we’re going to use:

• • Eclipse BPEL Designer and Eclipse IDE

  • Eclipse WTP

  • Riftsaw BPEL runtime

  • Jboss Application Server

  • some Jboss-compatible WS stack (native or CXF)

  • JAX-WS for generating java services and clients

To make all of this happen there are quite a few services and database resources that need to participate. At a minimum, we will need the following:

• Seat Availability Notification System (SANS) - this is the “client” that kicks off the entire process, although the Flight Reservation System may already have this data available. Starting at one hour before the scheduled departure time, this system needs to send messages to the LaMiPU process, one for each premium seat still available for that flight. Since the response from LaMiPU may take several minutes (depending on how long the customer interaction takes), this will have to be an async request/response. LaMiPU will respond with either “accepted” or “rejected” indicating whether the customer has accepted or rejected the seat upgrade. The process may also respond with a fault under certain situations (e.g. if the flight has already departed). If “accepted”, the client marks the seat as “occupied”, and the seat previously occupied by the passenger (presumably an “economy” seat) as available. This economy seat can then be made available to stand-by customers, but that’s out of scope for this project. Most likely this client is specific to the airline and will likely have to be cobbled together from existing resources.

• Flight Reservation System (FRS) – this service returns the passenger list for a given flight. Passenger status includes whether or not they have already checked in for a flight.

• Flight Scheduling Service (FSS) – this service returns the scheduled departure time for a given flight. A quick internet search for web services that already offer this functionality turns up quite a few hits, in particular: http://flightaware.com/commercial/flightxml/documentation2.rvt Not that our solution will use this service (because I didn’t want to be on the hook for subscribtion fees just so I could blog about BPEL) but it does provide a blueprint for an existing API that we can use. The airline will probably already have their own system, or subscribe to one.

• Frequent Flyers Database (FFDB) – this system is used to look up checked-in passengers and find our “loyal customers”. Hmm, since we’re going to be using Riftsaw which is based on Apache ODE maybe we can take advantage of JDBC mapping of BPEL variables. Of course we’ll have to write a BPEL Editor extension to deal with this (another shameless plug for a future blog topic )

• Credit Card Authorization System (CCAS) – used for credit card authorization and billing for upgrade fees. There are tons of these available, and the airline will have one or more which it uses regularly and which may already have a WSDL interface; our system just needs access to those services.

• IVR System – this is the fun stuff check out http://trixbox.org LaMiPU will use IVR for interaction with passengers so we’ll write a web service using a top-down approach to building a java application. Hopefully we can get the text to speech feature working.

The Work flow

Here’s the basic sequence of events, disregarding possible failure or exception conditions for the moment:

1. SANS client sends messages to LaMiPU, one for each available seat
2. This message starts a LaMiPU process, using the flight# and seat# as the correlation key.
3. LaMiPU sends a message to the FSS requesting departure time for the given flight#. If it’s too late to get the seat reassignment done before departure, LaMiPU replies to SANS with a fault message.
4. LaMiPU contacts the FRS to get the list of passengers that have already checked in for a given flight.
5. For each of the passengers returned in 4 that do not already have a premium seat assignment (business or first class), LaMiPU searches the FFDB for those passengers. If the FFDB indicates that the passenger has not already received a seat upgrade offer for this flight, LaMiPU prepares to contact that passenger using the IVRS. If there are no more passengers to contact, a fault is returned to the SANS client. NOTE: we could modify this logic a bit by offering seat upgrades to regular passengers at a much higher premium, but this is outside the scope of this project. Besides, the point of this exercise is not to sell out all premium seats but to demonstrate as many BPEL features as possible
6. For the passenger returned by 5, prepare a seat upgrade offer message for the IVRS consisting of the passenger’s name, the flight# and the price for the upgrade.
7. If the passenger accepts the offer, bill his/her credit card and notify the FRS of the seat assignment change, wait for a response and send a verification message to the customer. Also update the FFDB to indicate that the customer has been contacted and accepted the seat upgrade. This becomes “interesting” information for marketing, and may lead to follow-on work to enhance the system ;). Finally, send a message back to the SANS with “accepted” status.
8. If the passenger declines the offer, update the FFDB to indicate the customer has been contacted but has declined the upgrade. Send a message back to the SANS with “rejected” status.

This is just the basic “happy path” flow. Keep in mind that there are all kinds of failure modes here which have to be dealt with. I’ll get into these in more detail in my next blog.

In the last two months Xtext got a great number of performance and memory footprint improvements, bug fixes and extensive documentation enhancements (most of them done by Sebastian while us others were on summer vacation :-)). We also fixed a couple of annoying bugs in Xpand's editor.

You can find a detailed list of all 89 fixes in this bugzilla query.

If you are familiar with the embedded browser in the Lotus products you may or may not have heard of BrowserFunction, most likely not!  The problem is this class is not very well documented and was part of E4 and is scheduled for Eclipse 3.6.  Notes 8.5.2 does however support this SWT class so you can begin to play with it once 8.5.2 is available.

Why is this so important?  Well, just imagine, now you can completely communicate between Java and JavaScript using this.  You can use the SWT Browsers execute() or evaluate() methods to execute JavaScript from Java and now you can execute Java from JavaScript using BrowserFunction.

This implies you could potentially write all of your UI using HTML/CSS/JavaScript technologies!

The Attachment viewer is such an application, you can check out the code on OpenNTF.  I don’t use the BrowserFunction in the OpenNTF version but I have already begun to make an Lotus Notes 8.5.2 version of the plugin that has much better integration with the Notes client.  If you are writing side bar plugins and want to standardize on writing in a single technology you should check out the SWT Browser and the BrowserFunction support.

For a small scrum tool that we are currently developing on top of the Riena framework, we wanted to visualize the progress of user stories and tasks carried out by a developer. We would usually use a ProgressBar widget to display such a progress. However, as we soon realized, this widget has a number of drawbacks.

A ProgressBar is usually used to display the progress of a much shorter time span, a file operation for example. This assumption found its way into OS design decisions. For instance, since Vista, the ProgressBar on Windows features a highlight perpetually running back and forth to indicate that the process is still running. This is rather irritating when several ProgressBars are used on one view. Also, if a ProgressBar was hidden due to a scrolling operation and comes back into view, it gradually fills up to the value currently set. As with many other SWT widgets, the possibilities to alter color or design are very limited. We wanted to change the color when a task is completed to indicate the difference between “the estimated/allotted time has been used” and “the task has been completed”.

Long story short, we wrote a new widget, the StatusMeter. It dynamically creates an image, giving us absolute control over all its properties. We now can change the color to reflect different states. There is a ridget in place so it feels like any other widget used in Riena. And since the main part of this widget is the image, it also gives us the opportunity to use it inside of table columns (for example via Riena’s ColumnFormatter). Thus we can now visualize percentages in table columns just as easy as we visualize boolean values with a checkbox.

The widget is called StatusMeterWidget. If you want to use it in a table column, use StatusMeter directly to create just the image. Both are available via CVS. Feel free to send screenshots of how you use it in your application.

New Plug-in Wizard

public XMLEditor() {
 super();
 colorManager = new ColorManager();
 setSourceViewerConfiguration(new XMLConfiguration(colorManager));
 setDocumentProvider(new XMLDocumentProvider());
}

public XMLEditor() {
 super();
 colorManager = new ColorManager();
 setSourceViewerConfiguration(new XMLConfiguration(colorManager, getPreferenceStore()));
 setDocumentProvider(new XMLDocumentProvider());
} 

public class XMLConfiguration extends TextSourceViewerConfiguration { //SourceViewerConfiguration {
...
public XMLConfiguration(ColorManager colorManager, IPreferenceStore preferenceStore) {
 super(preferenceStore);
 this.colorManager = colorManager;
}
...

/**
* Providing custom XMLSpellingReconcileStrategy to enable spell checking for only strings
*/
/* (non-Javadoc)
* @see org.eclipse.jface.text.source.SourceViewerConfiguration#getReconciler(org.eclipse.jface.text.source.ISourceViewer)
*/
public IReconciler getReconciler(ISourceViewer sourceViewer) {
 XMLSpellingReconcileStrategy strategy = new XMLSpellingReconcileStrategy(sourceViewer, EditorsUI.getSpellingService());
 Reconciler reconciler = new Reconciler();
 reconciler.setReconcilingStrategy(strategy, XMLStringPartitionScanner.XML_STRING);
 reconciler.setDocumentPartitioning(XMLStringPartitionScanner.XML_STRING);
 return reconciler;
}

public class XMLStringPartitionScanner extends RuleBasedPartitionScanner {

 public final static String XML_STRING = "__xml_string";

 public XMLStringPartitionScanner() {
  IToken stringToken = new Token(XML_STRING);
  IPredicateRule[] rules = new IPredicateRule[1];

  rules[0] = new MultiLineRule("\"", "\"", stringToken, '\\');
  setPredicateRules(rules);
 }
}

public class XMLSpellingReconcileStrategy extends SpellingReconcileStrategy {

 public XMLSpellingReconcileStrategy(ISourceViewer sourceViewer, SpellingService spellingService) {
  super(sourceViewer, spellingService);
 }
 ...
 public void reconcile(IRegion region) {

  AbstractDocument document = (AbstractDocument) getDocument();
  IDocumentPartitioner docPartitioner = document.getDocumentPartitioner(XMLStringPartitionScanner.XML_STRING);

  IAnnotationModel model = getAnnotationModel();
  if (region.getOffset() == 0 && region.getLength() == document.getLength()) {
  //reconciling whole document
  super.reconcile(region);
  deleteUnwantedAnnotations();
  } else {
   //partial reconciliation
   //preserve spelling annotations first
   Iterator iter = model.getAnnotationIterator();
   Map spellingErrors = new HashMap(1);
   while (iter.hasNext()) {
    Annotation annotation = (Annotation) iter.next();
    if (annotation instanceof SpellingAnnotation) {
     SpellingAnnotation spellingAnnotation = (SpellingAnnotation) annotation;
     Position position = model.getPosition(spellingAnnotation);
     String contentType = docPartitioner.getContentType(position.getOffset());

     if (XMLStringPartitionScanner.XML_STRING.equalsIgnoreCase(contentType)) {
      spellingErrors.put(spellingAnnotation, model.getPosition(annotation));
     }
    }
   }

   //reconcile
   super.reconcile(region);

   //restore annotations
   model = getAnnotationModel();
   iter = spellingErrors.keySet().iterator();
   while (iter.hasNext()) {
    Annotation annotation = (Annotation) iter.next();
    model.addAnnotation(annotation, (Position) spellingErrors.get(annotation));
   }
   deleteUnwantedAnnotations();
  }

 }

 /**
 * Deletes the spelling annotations marked for XML Tags
 */
 private void deleteUnwantedAnnotations() {
  AbstractDocument document = (AbstractDocument) getDocument();
  IDocumentPartitioner docPartitioner = document.getDocumentPartitioner(XMLStringPartitionScanner.XML_STRING);
  IAnnotationModel model = getAnnotationModel();
  Iterator iter = model.getAnnotationIterator();

  while (iter.hasNext()) {
   Annotation annotation = (Annotation) iter.next();
   if (annotation instanceof SpellingAnnotation) {
    SpellingAnnotation spellingAnnotation = (SpellingAnnotation) annotation;
    Position position = model.getPosition(spellingAnnotation);
    String contentType = docPartitioner.getContentType(position.getOffset());
    if (!XMLStringPartitionScanner.XML_STRING.equalsIgnoreCase(contentType)) {
     model.removeAnnotation(spellingAnnotation);
    }
   }
  }
 }
}

public class XMLDocumentProvider extends FileDocumentProvider {

 protected IDocument createDocument(Object element) throws CoreException {
  IDocument document = super.createDocument(element);
  if (document != null) {
   IDocumentPartitioner partitioner = new FastPartitioner(new XMLPartitionScanner(), new String[] {XMLPartitionScanner.XML_TAG, XMLPartitionScanner.XML_COMMENT});
   partitioner.connect(document);
   document.setDocumentPartitioner(partitioner);

   //Adding our string partition scanner to the document
   partitioner = new FastPartitioner(new XMLStringPartitionScanner(), new String[] {XMLStringPartitionScanner.XML_STRING});
   partitioner.connect(document);
   ((AbstractDocument) document).setDocumentPartitioner(XMLStringPartitionScanner.XML_STRING, partitioner);
  }
  return document;
 }
}

I am happy to announce that EGit is not the only Eclipse project that had a successful Summer of Code this year. Just as the program is wrapping up, a first version of the new Mylyn Hudson connector has been uploaded to the Mylyn weekly incubator update site. I had the pleasure to mentor Markus Knittig who did a great job over the summer in getting the connector into its current state. While there is still quite a bit of work to do, I have already been using the connector on a daily basis to monitor builds.

The Hudson connector is based on the Mylyn Builds framework which provides common infrastructure for integrating build servers with Eclipse. Most importantly it provides a Builds view.

The view shows the status and health for subscribed jobs. Red indicates a failed build, yellow failed tests and green means a build was successful. The weather icons in the Summary column show how a build has been doing in recent history following the Hudson web interface.

One really neat feature is the decoration of the view icon which shows the overall status when the view is in fast-view mode. When auto refresh is enabled the decoration icon will show a black or red X once a builds fails very similar to how the JUnit view indicates failed tests.

Subscribing to jobs, which are called plans in the Builds framework, is straight forward from the build server properties page which closely follows the settings page for Mylyn task repositories. All selected plans are shown and monitored in the Builds view.

If you feel brave and want try out the Hudson connector add the following P2 repositories to Eclipse 3.5 or later:

http://download.eclipse.org/tools/mylyn/update/weekly
http://download.eclipse.org/tools/mylyn/update/weekly/incubator

Note that the connector is still work in progress and it is likely that the data model will change in future versions possibly requiring re-configuration of servers. I recommend checking the weekly Mylyn New & Noteworthy every once in a while which will lists any significant enhancements or changes.

The Mylyn Bugzilla lists plenty of ideas how to move forward but I would love to hear from the community what features would be most valuable to you. Please feel free to file bugs against Mylyn or chime in on the discussion on one of the existing feature requests.

There has been talk about moving the Hudson connector in its own Eclipse sub-sub-project. Please drop me a line or comment on bug 308040 if you are interested in getting involved.

Brief note: I'm excited to be presenting the talk "Eclipse in the Enterprise: Lessons from Google" at Eclipse Enterprise Days on Oct 13 in Reston, VA.

This looks like a great conference for people who support large Eclipse user bases -- you know who you are -- if you attended the Eclipse in the Enterprise BoF at EclipseCon, this conference is for you. From the conference page:

"Attendees must be an employee or contractor of an "Enterprise User" of Eclipse technology. Enterprise users typically are responsible for the use of Eclipse by hundreds and even thousands of developers in their organizations."

workspaceRoot.delete(true, false, new NullProgressMonitor());

deleteAll(IProgressMonitor monitor);

delete(IProgressMonitor monitor);

forceDeleteAll(IProgressMonitor monitor);

forceDelete(IProgressMonitor minitor);

So far EGit’s History View could only display the commits reachable from the current HEAD.

Here how this looks for the git.git repo when the branch remote/maint is checked out :

git.git repo, origin/maint checked out

Jens Baumgart today added a little toggle button which will do all the magic :

Together with my still pending change http://egit.eclipse.org/r/#change,1359
to also show all remote tracking branches this becomes “gitk -all for Eclipse” :

git.git in EGit, showing all branches, branch origin/maint checked out

In my last post I blogged about how Chart Scripting works in BIRT. If you are using Actuate BIRT, you also will have access to Flash Charts and Gadgets. Scripting for these two report items is very similar to the standard Chart scripting model.



Flash Charts
Currently Flash charts support 14 script event triggers that can be hooked to make chart modifications.



The event firing order is shown below.



As you can see the order is very similar to that of normal BIRT charts. The before and after dataset filled events are fired first for each dataset (category and value). Next the beforeRendering event is fired and then the before and after draw series events are fired for each series. Between the before and after draw series events the before and after draw data point events are fired for each point in the series. The before and after draw series events (and the events contained in them) are fired for each series in the chart. After all series are processed, the before and after draw effect events are fired for each effect in the chart. Effects can be used to alter the chart at runtime, allowing font manipulation, blurring, glowing, shadowing, beveling, and animation of different objects of the chart. Effects are added to the chart using the effects editor.



Using the beforeDrawEffect event script you can alter any of the effects added to the chart. For example to turn off the shadow effect in the above chart you could use the following script.




function beforeDrawEffect( effect, fcsc )
{
var effectName = "MyTitleEffect";
if ( effectName.equals( effect.getAction().getName() ) ){
if( effect.getAction().getShadow() != null ){
effect.getAction().getShadow().setEnabled(false);
effect.getAction().getFont().setEnabled(false);
}
}
}

function beforeRendering( flashChart, fcsc )
{
var parmChartTitle = fcsc.getExternalContext().getScriptable().getParameterValue("MyChartTitle");
flashChart.getChart().getTitle().getLabel().getCaption().setValue(parmChartTitle)
}

function beforeRendering( gadget, fgsc )
{
 var vals=gadget.getResultValues();
 for( i = 0; i < vals.size(); i++ ){
  if( vals.get(i).getValue() > 20 ){
   //do something
  }
 }
}

function beforeDrawRegion( region, fgsc )
{
 if( region.getLabel().equals("A") ){
  region.setColor("00ff00");
 } 
   //Display value range of region.   
     region.setLabel( "(" + region.getStartValue() + ", " + region.getEndValue() + ")" ); 
    
}

function beforeRendering( gadget, fgsc )
{
 //First Region
 gadget.getRegion().get(0).setEndValue(25);
 //Second Region
 gadget.getRegion().get(1).setStartValue(25);

function beforeDrawThreshold( threshold, fgsc )
{
  if( threshold.getLabel().equals("MyThreshold") ){
   threshold.setShowValueInside(true);
   threshold.setShowValueOnTop(false);
   threshold.setStartValue(10);
   threshold.setColor("0000ee");
  // Display the value range of threshold.
   threshold.setLabel( "(" + threshold.getStartValue() + ", " + threshold.getEndValue() + ")" );
  }
}

function beforeRendering( gadget, fgsc )
{
 gadget.getThresholds().get(0).setMarkerColor("ff0000");
}

function beforeDrawAddOn( addOn, fgsc )
{
 // Change add-on styles. 
 if ( addOn.getName().equals("TitleAddOn") )
 {
  addOn.setLabel( "Meter Gauge" );
  addOn.setFontColor( "ff0000" );
  addOn.setFontSize( 28 );
  addOn.setY( 35 );
 }
 else if ( addOn.getName().equals( "ArcAddOn" ) )
 {
  addOn.setFillColor( "ffff00" );
 }
} 

function beforeRendering( gadget, fgsc )
{
  importPackage( Packages.com.actuate.birt.flash.gadgets );
  importPackage( Packages.com.actuate.birt.flash.gadgets.impl );
  
  // Add a text add-on.
  var textAddOn = GadgetsFactory.eINSTANCE.createTextAddOn();
  textAddOn.setAddOnType( AddOnType.TEXT );
  textAddOn.setName("DescAddOn");
  textAddOn.setShowAddOn(true);
  gadget.getAddOns().add( textAddOn );
  gadget.setZOrderPosition(1);
 
 textAddOn.setLabel("This sample demonstrates how to add an add-on by scripting.");
 textAddOn.setX(2);
 textAddOn.setY(20);
 textAddOn.setFontSize( 12 );
 textAddOn.setHorizontalAlignment( HorizontalAlignmentType.LEFT );
 textAddOn.setVerticalAlignment( VerticalAlignmentType.TOP );
 textAddOn.setWrap( true );
 textAddOn.setTextBoxBorderColor("000000"); //Black
 textAddOn.setTextBoxBackgroundColor("c0c0c0");
 textAddOn.setWrapMaxWidth( 30 );
 textAddOn.setWrapMaxHeight( 50 );
 
}

function beforeDrawNeedle( needleWrapper, fgsc )
{
   importPackage( Packages.com.actuate.birt.flash.gadgets );
   importPackage( Packages.com.actuate.birt.flash.gadgets.impl );
   // Change needle styles.
   needleWrapper.getNeedle().setShape( Shape.DIAMOND );
   needleWrapper.getNeedle().setFillColor("2cf83a");
   needleWrapper.getNeedle().setBorderColor("007f00");
}

function beforeDrawNeedle( needleWrapper, fgsc )
{  
   //Set Needle size to 25%
   needleWrapper.getMeterNeedle().setSize(25);
   needleWrapper.getMeterNeedle().setBackgroundColor("ff0000");
}

Unless you have been stranded on a deserted island for the last few years you’re probably aware that JBoss/Red Hat has been making some huge contributions in the middleware technology space, both on the tooling and runtime side. The announcements of JBoss Tools (the community supported edition) and JBoss Developer Studio (the fully supported, enterprise version) represent an impressive offering of developer tools, plug-ins, APIs, UI components and execution engines that make the SOA architect’s life worth living again. The tooling is built on top of the Eclipse Workbench as a collection of plug-ins and is compatible with the current “Helios” release of eclipse.

JBoss Tools combines best-of-breed open source and in-house developed software and packages it all up in a neat little bundle so that you can be reasonably assured all of the pieces are going to play nice together. This is no small feat, considering that some of the bits of open source software have all kinds of different version interdependencies and conflicts, a problem which Eclipse plug-in developers have simply accepted as the price to be paid for the privilege of getting to play with really cool stuff.

One of these components, which “yours truly” has recently become very involved in, is the BPEL Designer project. It seems that while there has been lots and lots of interest in the community for an editor (other than “vi” or “emacs”) that offers not just an enjoyable user experience but also handles validation reasonably well, there has been little progress over the past three years or so. The reasons for the seeming lack of interest in the developer community to contribute to a product that is obviously of great interest, are unknown and unimportant. What is important is that we as a community rekindle the spark and start moving this project forward again.

Because of my previous experience building EMF/GEF editors, middleware and the like, I have [been] volunteered to “take the helm” and try to help in sparking interest in the community. Over the past few weeks, Wayne Beaton has been extremely helpful in making this happen (thanks Wayne!) and, hopefully, in the next few weeks we will see a renewed energy over at eclipse.org/bpel

Here are some ideas we’d like to see happen in the near future:

1. Stabilize the code. It’s “pretty good” currently and will even [almost] build and run on Helios, but there’s always room for improvement.
2. Start doing nightly or snapshot builds at eclipse.org and make them available to the community.
3. Migrate the existing CVS repository to Git to ease the pain of source code management.
4. Get on the eclipse release train. It’s very painful trying to jump a plug-in by more than one major release of eclipse and making sure that we’re always compatible with the current release goes a long way in community acceptance.
5. Strongly “encourage” committers to use TDD methodologies to ensure code quality: submitting a patch? submit a JUnit or SWTBot test along with it, and get a prize!
6. Move the project out of incubation and into a top-level project (WTP? SOA? Any takers out there?)

If anyone in the community has any other suggestions, I’d be more than happy to discuss them. We’re always looking for suggestions and help with bug fixes or implementing new features. Please email me at bbrodt@redhat.com, or simply reply to this blog post.

I’m pleased to announce that demand for the OSGi and Equinox book has been quite high. Certainly not NY Times bestseller material but in the 6 months since it has been out we have shipped almost 3500 copies. For context, we are told that selling a total of 10,000 copies for tech a book is a very reasonable number so this is a great start.  In any event, the publisher is running a second printing next week as they are almost out of copies. Paul, Simon and I are just finishing up a few editorial changes and corrections to incorporate reader feedback (thanks!) and then its off to the presses.  Again.

Yesterday I showed how Xtext 1.0 projects can be build with Maven Tycho. So why shouldn’t the same setup don’t work for ‘old’ openArchitectureWare Xpand projects? This works like a charm. I took the simple project that the Xpand project wizard creates and added the POM, and it worked! You can download the sample project here. See the POM below, a setup for other oAW Xpand projects should be rather similar.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>p2.osgi.bundle</groupId>
	<artifactId>org.openarchitectureware.example.xpand.tycho</artifactId>
	<version>1.0.0</version>
	<packaging>eclipse-plugin</packaging>
	<name>org.openarchitectureware.example.xpand.tycho</name>

	<properties>
		<version.tycho>0.9.0</version.tycho>
	</properties>

	<build>
		<resources>
			<resource>
				<directory>src</directory>
			</resource>
		</resources>
		<plugins>
			<plugin>
				<groupId>org.sonatype.tycho</groupId>
				<artifactId>tycho-maven-plugin</artifactId>
				<version>${version.tycho}</version>
				<extensions>true</extensions>
			</plugin>
			<plugin>
				<groupId>org.sonatype.tycho</groupId>
				<artifactId>target-platform-configuration</artifactId>
				<version>${version.tycho}</version>
				<configuration>
					<resolver>p2</resolver>
				</configuration>
			</plugin>
			<plugin>
				<groupId>org.fornax.toolsupport</groupId>
				<artifactId>fornax-oaw-m2-plugin</artifactId>
				<version>3.1.0-SNAPSHOT</version>
				<configuration>
					<workflowEngine>oaw</workflowEngine>
					<workflowDescriptor>workflow/generator.oaw</workflowDescriptor>
				</configuration>
				<executions>
					<execution>
						<phase>generate-sources</phase>
						<goals>
							<goal>run-workflow</goal>
						</goals>
					</execution>
				</executions>
			</plugin>
			<plugin>
				<artifactId>maven-clean-plugin</artifactId>
				<version>2.4.1</version>
				<configuration>
					<filesets>
						<fileset>
							<directory>src-gen</directory>
							<includes>
								<include>**/**</include>
							</includes>
						</fileset>
					</filesets>
				</configuration>
			</plugin>
		</plugins>
	</build>
	<repositories>

		<repository>
			<id>p2.openarchitectureware</id>
			<url>http://www.openarchitectureware.org/updatesite/milestone/</url>
			<layout>p2</layout>
		</repository>
		<repository>
			<id>p2.eclipse.helios</id>
			<url>http://download.eclipse.org/releases/helios</url>
			<layout>p2</layout>
		</repository>
		<!-- At the moment the Fornax plugin is only available as snapshot -->
		<repository>
			<id>fornax-snapshots</id>
			<url>http://www.fornax-platform.org/archiva/repository/snapshots/</url>
			<releases>
				<enabled>false</enabled>
			</releases>
			<snapshots>
				<enabled>true</enabled>
			</snapshots>
		</repository>
	</repositories>
	<pluginRepositories>
		<pluginRepository>
			<id>fornax-snapshots</id>
			<url>http://www.fornax-platform.org/archiva/repository/snapshots/</url>
			<releases>
				<enabled>false</enabled>
			</releases>
			<snapshots>
				<enabled>true</enabled>
			</snapshots>
		</pluginRepository>
	</pluginRepositories>
</project>

After a month, some bugs from the Debug Visualisation version 0.8.0 have been fixed. Most notably, the incorrect trimming of long titles, and a case, where arcs were incorrectly removed from the graph.

Two minor new features were also introduced: it is possible to turn off name trimming, and the values of variables is now displayed as a hover.

I created a screencast to show these new features (and also some other, as the last screencast was created over a year ago.

(If the embedded video does not show in your feed reader, you can watch it on YouTube.)

Joining an ongoing simultaneous release is something you won’t forget: lots of things to check, lots of things to make compliant, lots of milestones coming up, lots of things to check again for the next milestone… yeah, it’s a bit of a hush, hehehe! But it is a nice, warm feeling when you see things on schedule and even more when the release train ends and your project is there, with all other projects that were steps ahead of you!

This happened for Sequoyah from the last months of 2009 to this June, when Sequoyah was adapting from being an incubation project and developing to maturity, to be released together with Eclipse Helios. I am saying most of this for myself, but I don’t think it was much different for my teammates. The hush and the warm feeling are the same!

Now, for Indigo release train, we are in a much more comfortable position, since we are already compliant with lots of those items, and we know a little bit more on how the process works (even though we still come with some newbie questions sometimes, as the guys on cross-project-dev mailing list would easily confirm, hehe). But for this release we already know when we should make our builds available for the aggregator, when will the packages come for us to test, which bugs to merge for the next build, and things like that.

This was actually the reason I started to write this post:
we have joined the Eclipse Indigo Simultaneous Release Train!

As of today, we have our 1.1.0.I20100816-0145 Sequoyah build available for the Indigo aggregator to build the composite repository for the first milestone. We have also made available a new build of the Pulsar plugins, namely 1.1.1.I20100816-0515.

Things will probably change a lot before the RC weeks come next year, but it’s now a much more fun work to do, knowing a little bit of what to expect! I’ll try to share some more of my experience in the weeks to come. If it is not useful for you, maybe you just laugh a little, and that’s fine too! See you around!

(posted by Daniel Pastore)

The Google Summer of Code program for 2010 has wrapped up recently.

Eclipse participated this year and I’m not sure how all of our projects did, but I can at least tell you how things went with the project I was involved with. I and the rest of the EGit team (mostly Matthias Sohn) mentored Dariusz Luksza in providing some much needed enhancements to the EGit project. Dariusz started out with some smaller items such as adding tagging support but eventually moved on to more complicated endeavors like implementing support for the synchronize view. All I can say is that the project went really well and I recently was proud to nominate Dariusz as a committer.

In the past, there have been other successful transitions from GSOC alumni to committer. It’s even helped some people get jobs! For example, Remy Suen had to endure my mentorship four years ago or so and now he’s having fun working at IBM hacking on Eclipse 4.0 amongst other things. I’m sure there are other examples out there that aren’t coming to my mind at the moment.

In the future, it would be good to see more projects at Eclipse.org involved in GSOC and mentoring students. Just a little of your time can have a positive effect on a student and the open source community as a whole. In my opinion, working with potential contributors and more importantly students, is one of the best things we can do for ourselves within the Eclipse community to keep things vibrant.

...scares the hell out of me. Apple recently announced the iPad and unless you're living under a rock you've heard about it and probably the brouhaha over its refusal to allow Flash. Apparently the iPad won't allow any browser plugins. I am scared to hell.

Web/browser-based applications are the future. We will continue to move further away from the desktop. Soon enough, almost all widespread software will be browser-based. Today that means HTML+Javascript, plus Flash, Silverlight, Java or any other plugin-based approach. If Steve Job's has his way, we won't have any plugins. The Open Web crowd want the same. So just HTML and Javascript. Regardless of how you feel about HTML+Javascript today, everyone has to agree that the rate of innovation here is very very slow. The HTML5 mess including the recent spat about video codecs shows us again that Design by Committee is the worst sort of process.

Now imagine a world where this is the ONLY avenue for new innovations in client-side languages and platforms. If we remove plugins this is all we have left. On the client side, there will be no new languages - just Javascript. There will be no new languages to sprout up like Java or Ruby have done in the past decade. Nope - Javascript is the standard. Nobody will have the motivations (i.e. there will be no money in it) or ability to add a new language to the browser standards. And there will be no way around this via plugins.

Steve Jobs certainly has his master plan and hopes to make large sums of money on the iPad and the continuing dominance of the iPhone. But the Open Web folks seemingly come from a more philosophic/political agenda - "The Web Should be Free". What happens when that comes true. What happens when we've successfully prevented all corporate interests from profiting off client technologies on the internet? Then certainly no companies will invest in the client technologies. We've salted our own fields. We've put our sole hope for new innovation in a committee process thats proven itself time and time again, both in general theory and in specific practice of these groups, to be slow and fraught with problems.

We're proud to announce the public beta of ReviewMate, the best (in our opinion) code review tool for Eclipse.

ReviewMate is different from other code review tools because it allows you to add comments right in the context of the code itself. No more entering code comments in awkward forms. Simply highlight a few lines of code, click the Comment button, and your new comment bubble will appear in the right margin.



Thanks to ReviewMate's innovative technique for code formatting, almost any programming language can be handled by the ReviewMate editor. Even formats like HTML and SQL. If you're Eclipse IDE can format the file, so can ReviewMate.

Check out the ReviewMate page on ElementRiver.com and sign up for the free public beta.

Just a small reminder that you still have to register for the OSGi Community Event, September 29-30 in London! We really have a very strong program this year, there are lots of very interesting presentations. From the program it is clear that OSGi is maturing in many verticals of the software industry. From the Appstore for the connected home market to the enterprise application twins Apache

Here are three recent developments from Eclipse Riena, that you may otherwise have missed:

• Version 3.0 announced – we have updated the development plan, skipping the 2.1 release and shooting straight for a 3.0 release next June (Eclipse Indigo). While we strive to keep the bulk of the APIs unchanged, this move will grant us the flexibility to carefully introduce changes needed to support Eclipse RAP.

You can read the full announcement here.

• Riena goes to the Web – We are excited about having all of Riena run on Eclipse RAP and are stepping up the effort.

In the last two weeks we have ported and committed the Riena Navigation to RAP. Thanks to recent improvements in RAP this was a breeze! We also have an automated build for this second platform. Lastly, we have worked to eliminate all compile errors when building against RAP. This should make further development more straightforward.

If you want to follow the effort add yourself on Bug 302893 and read the ‘Riena on RAP‘ page on the wiki.

• Riena at Eclipse Summit Europe - Riena committers are participating at the ESE, November 2 – 4 in Ludwigsburg. We have proposed following talks:

• Riena on RAP (Running Riena in the Web)
• Riena on e4 aka “RCP 2.0″
• SWT on Qt
• Tutorial: dynamic UI – from domain model to RCP app (Riena+Modelling+RedView)

If you are interested in any of these topics: please follow the link and leave a short comment. This will help the organizers decide which talks to approve. Thanks!

Here are the slides from my “Eclipse RAP – What’s new in Helios?“ talk, which I gave at the Bay Area Demo Camp in June. They capture the most interesting novelties of the RAP 1.3 release. You can find even more details in the full release notes.

I want to thank Oracle and AvantSoft for hosting and organizing the event.

If you are interested in future Eclipse events in the Bay Area, please take a moment to join the Bay Area Eclipse User Group on Meetup.com

During the last week or so I modernized a part of the Object Teams Development Tooling (OTDT) that had been developed some 5 years ago: the type hierarchy for OT/J. I’ll mention the basic requirements for this engine in a minute. While most of the OTDT succeeds in reusing functionality from the JDT, the type hierarchy was implemented as a full replacement of the original. This is a pretty involved little machine, which took weeks and months to get right. It provides its logic to components like Refactoring and the Type Hierarchy View.

On the one hand this engine worked well for most uses, but over so many years we did not succeed to solve two remaining issues:

Give a faithful implementation for getSuperclass()

This is tricky because a role class in OT/J can have more than one superclass. Failing to implement this method we could not support the “traditional” mode of the hierarchy view that shows both the tree of subclasses of a focus type plus the path of superclasses up to Object (this upwards path relies on getSuperclass).

Support region based hierarchies

Here the type hierarchy is not only computed for supertypes and subtypes of one given focus type, but full inheritance structure is computed for a set of types (a “region”). This strategy is used by many JDT Refactorings, and thus we could not precisely adapt some of these for OT/J.

In analyzing this situation I had to weigh these issues:

• In its current state the implementation strategy was a show stopper for one mode of the type hierarchy view and for precise analysis in several refactorings.
• Adding a region based variant of our hierarchy implementation would mean to re-invent lots of stuff, both from the JDT and from our own development.
• All this seemed to suggest to discard our own implementation and start over from scratch.

Object Teams to the rescue: Let’s re-build Rome in ten days.

As mentioned in my previous post, the strength of Object Teams lies in building layers: each module sits in one layer, and integration between layers is given by declarative bindings:

Applying this to the issue at hand we now actually have three layers with quite different structures:

Java Model

The bottom layer is the Java model that implements the containment tree of Jave elements: A project contains source folders, containing packages, containing compilation units, containing types containing members. In this model each Java type is represented by an instance of IType

Java Type Hierarchy

This engine from the JDT maintains the graph of inheritance information as a second way for navigating between ITypes. Interestingly, this module pretty closely simulates what Object Teams does natively, I may come back to that in a later post.

Object Teams Type Hierarchy

As an extension of Java, OT/J naturally supports the normal inheritance using extends, but there is a second way how an inheritance link can be established: based on inheritance of the enclosing team:

team class EcoSystem {
   protected class Project { }
   protected class IDEProject extends Project { }
}
team class Eclipse extends EcoSystem {
   @Override
   protected class Project { }
   @Override
   protected class IDEProject extends Project { }
}

Here, Eclipse.Project is an implicit subclass of EcoSystem.Project simply because Eclipse is a subclass of EcoSystem and both classes have the same simple name Project. I will not go into motivation and consequences of this language design (that’ll be a separate post — which I actually promised many weeks ago).

Looking at the technical challenge we see that the implicit inheritance in OT/J adds a third layer, in which classes are connected in yet another graph.

Three Layers — Three Graphs

Looking at the IType representation of Eclipse.IDEProject we can ask three questions:

Each question is implemented in a different layer of the system. Things get a little complicated when asking a type for all its super types, which requires to collect the answers from both the JDT hierarchy layer and the OT hierarchy. Yet, the most tricky part was giving an implementation for getSuperclass().

An "Impossible" Requirement

There is a hidden assumption behind method getSuperclass() which is pervasive in large parts of the implementation, especially most refactorings:

When searching all methods that a type inherits from other types, looping over getSuperclass() until you reach Object will bring you to all the classes you need to consider, like so:

IType currentType = /* some init */;
while (currentType != null) {
   findMethods(currentType, /*some more arguments*/);
   currentType = hierarchy.getSuperclass(currentType);
}

There are lots and lots of places implemented using this pattern. But, how do you do that if a class has multiple superclasses?? I cannot change all the existing code to use recursive functions rather than this single loop!

Looking at Eclipse.IDEProject we have two direct superclasses: Eclipse.Project (normal inheritance, “extends”) and EcoSystem.IDEProject (OT/J implicit inheritance), which cannot both be answered by a single call to getSuperclass(). The programming language theory behind OT/J, however, has a simple answer: linearization. Thus, the superclasses of Eclipse.IDEProject are:

• Eclipse.IDEProject → EcoSystem.IDEProject → Eclipse.Project → EcoSystem.Project

… in this order. And this is how this shall be rendered in the hierarchy view:

The final callenge: what should this query answer:

        getSuperclass(ecoSystemIDEProject);

According to the above linearization we should answer: Eclipse.Project, but only if we are in the context of the superclass chain of Eclipse.IDEProject. Talking directly to EcoSystem.IDEProject we should get EcoSystem.Project! In other words: the function needs to be smarter than what it can derive from its arguments.

Layer Instances for each Situation

Let’s go back to the layer thing:

At the bottom you see the Java model (as rendered by the package explorer). In the top layer you see the OT/J type hierarchy (lets forget about the middle layer for now). Two essential concepts can be illustrated by this picture:

• Each layer is populated with objects and while each layer owns its objects, those objects connected with a red line between layers are almost the same, they represent the same concept.
• The top layer can be instantiated multiple times: for each focus type you create a new OT/J hierarchy instance, populated with a fresh set of objects.

It is the second bullet that resolves the “impossible” requirement: the objects within each layer instance are wired differently, implementing different traversals. Depending on the focus type, each layer may answer the getSuperclass(type) question differently, even for the same argument.

The first bullet answers how these layers are integrated into a system: Conceptually we are speaking about the same Java model elements (IType), but we superimpose different graph structure depending on our current context.

Inside the hierarchy layer, we actually do not handle IType instances directly, but we have roles that represent one given IType each. Those roles contain all the inheritance links needed for answering the various questions about inheritance relations (direct/indirect, explicit/implicit, super/sub).

A cool thing about Object Teams is, that having different sets of objects in different layers ( teams) doesn’t make the program more complex, because I can pass an object from one layer into methods of another layer and the language will quite automagically translate into the object that sits at the other end of that red line in the picture above. Although each layer has its own view, they “know” that they are basically talking about the same stuff (sounds like real life, doesn’t it?).

Summing up

OK, I haven’t shown any code of the new hierarchy implementation (yet), but here’s a sketch of before-vs.-after:

Code Size

The new implementation of the hierarchy engine has about half the size of the previous implementation (because it need not repeat anything that’s already implemented in the Java hierarchy).

Integration

The previous implementation had to be individually integrated into each client module that normally uses Java hierarchies and then should use an OT hierarchy instead. After the re-implementation, the OT hierarchy is transparently integrated such that no clients need to be adapted (accounting for even more code that could be discarded).

Linearization

Using the new implementation, getSuperclass() answers the correct, context sensitive linearization, as shown in the screenshot above, which the old implementation failed to solve.

Region based hierarchies

The old implementation was incompatible with building a hierarchy for a region. For the new implementation it doesn’t matter whether it’s built for a single focus type or for a region, so, many clients now work better without any additional efforts.

The previous implementation only scratched at the surface – literally worked around the actual issue (which is: the Java type hierarchy is not aware of OT/J implicit inheritance). The new solution solves the issue right at its core: the new team OTTypeHierarchies assists the original type hierarchy (such that its answers indeed respect OT/J’s implicit inheritance). By performing this adaptation at the issue’s core, the solution automatically radiates to all clients. So I expect that investing a few days in re-writing the implementation will pay off in no time. Especially, improving the (already strong) refactoring support for OT/J is now much, much easier.

Need I say, how much fun this re-write was?

I made a plugin to run customized process to notify JUnit results. Before I introduced to notify JUnit results to Grows Eclipse Plugin beforeThen Ketan's comment, "+1 for a custom command line preference this would be useful to people on other operating system". I agreed with him.So I made a plugin.If you'd like to install the plugin, could you please download jar file and copy to your dropins folder in your Eclipse.Default setting is to run growlnotify.If you want to customize that process, please open preference page and choose "Java->JUnit->Process Notification" like below.

/usr/bin/notify-send -i /home/kompiro/>eclipse/icon.xpm ${summary} ${detail}

C:\Snarl_CMD_1.0\Snarl_CMD.exe snShowMessage 2 "${summary}" "${detail}

Last year I showed how Xtext 0.7.2 projects can be build with Maven. It requires the installation of all related plugins as Maven artifacts in a Maven2 repository, which is a rather hard and error prone task. I was asked many times since then whether I would install Xtext 1.0 artifacts or even milestone versions into the openArchitectureWare Maven2 repository. Although I can really understand this requirement my hope was that I could avoid this and show a way to enable the build with Maven Tycho. Now the time has come that Tycho is mature enough and finally I had the time to do the necessary extension for the Fornax Maven Workflow Plugin to support the recently added MWE2 workflow engine, which is used from Xtext now as default. Maven Tycho and the Fornax plugin will allow to build Xtext projects in the most natural way possible.

A basic requirement for software builds is that everything can be build just from the sources. Also it is a good practice that no generated sources are checked in into a source repository. Unfortunately this often does not hold for Xtext projects, since it is a quite hard task to execute the Xtext generator in a build process. Yes, it is possible, but until now users often have to solve it again and again. Search the net, most projects seen there will just check in all the sources. The Fornax plugin and Maven will standardize this behavior.

What do you need to enable Xtext DSL builds with Tycho? Not much. Basically a Maven 3 installation (the beta is enough) and access to the internet to access the public repositories. A better idea is to use a repository manager in the intranet (like Nexus) to act as proxy for the public repositories. You will have to add some POMs to your projects. That’s it.

I’ll show now how to enable the basic project that you get from the Xtext project wizard get build with Maven Tycho.

1. Install Maven 3

Download Maven 3 from Apache, unpack it and put the bin folder on your path. Check the installation by typing ‘mvn –version‘ in a shell. You should something like this:

mvn --version
Apache Maven 3.0-beta-1 (r935667; 2010-04-19 19:00:39+0200)
Java version: 1.6.0_20
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: de_DE, platform encoding: MacRoman
OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"

2. Create the Xtext project

Select in Eclipse File / New / Project / Xtext Project and leave all the defaults. The project name should be org.xtext.example.mydsl for this tutorial. The projects will be created and almost empty for now. The aim is to get everything build by just adding the POMs.

3. Adjust plugin manifests

With the default Manifests the build does not execute successfully. The build fails because it has problems to resolve the logging infrastructure. It is sufficient to add Import-Package entries to resolve SLF4J and Logback. Open the plugin Manifest of the org.xtext.example.mydsl project, go to the Dependencies page and add the following Imported Packages:

• ch.qos.logback.classic
• ch.qos.logback.core.joran.spi
• org.slf4j

Open the Manifest of org.xtext.example.mydsl.generator, add the same packages and additionally

• org.apache.commons.logging

4. Add POM files

Each project will get a POM file. A Parent POM will contain the common settings and will act as a reactor POM also. Normally the Parent POM is placed in the directory above the modules, or here the plugin projects. This would be the workspace root. In this example we will place the Parent POM in the DSL grammar project. To make builds easier this POM will have the default name pom.xml. On the other side we have to add also a POM for the grammar project itself. Since it will be in the same directory we have to find another name, and we will call it pom-grammar.xml. For the other projects (.generator and .ui) we will stay with pom.xml.

4.1 org.xtext.example.mydsl/pom.xml

The Parent POM configures the Tycho plugins and aggregates the grammar project, UI project and the generator. Also the required repositories are configured here. Note that the folder “src” is added as resource path, this will add this folder to the classpath. The workflow execution would fail if the workflow module cannot be found on the classpath.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>p2.osgi.bundle</groupId>
	<artifactId>org.xtext.example.mydsl.parent</artifactId>
	<version>1.0.0</version>
	<packaging>pom</packaging>
	<name>org.xtext.example.mydsl.MyDsl - Parent</name>

	<properties>
		<version.tycho>0.9.0</version.tycho>
	</properties>

	<modules>
		<module>./pom-grammar.xml</module>
		<module>../org.xtext.example.mydsl.ui</module>
		<module>../org.xtext.example.mydsl.generator</module>
	</modules>
	<build>
		<!-- The src directory must be named as resource dir to put it on the build classpath. This is required to resolve the
			workflow module named in the .mwe2 file -->
		<resources>
			<resource><directory>src</directory></resource>
		</resources>
		<plugins>
			<plugin>
				<groupId>org.sonatype.tycho</groupId>
				<artifactId>tycho-maven-plugin</artifactId>
				<version>${version.tycho}</version>
				<extensions>true</extensions>
			</plugin>
			<plugin>
				<groupId>org.sonatype.tycho</groupId>
				<artifactId>target-platform-configuration</artifactId>
				<version>${version.tycho}</version>
				<configuration>
					<resolver>p2</resolver>
				</configuration>
			</plugin>
		</plugins>
		<pluginManagement>
			<plugins>
				<plugin>
					<groupId>org.fornax.toolsupport</groupId>
					<artifactId>fornax-oaw-m2-plugin</artifactId>
					<version>3.1.0-SNAPSHOT</version>
					<configuration>
						<workflowEngine>mwe2</workflowEngine>
					</configuration>
					<executions>
						<execution>
							<phase>generate-sources</phase>
							<goals>
								<goal>run-workflow</goal>
							</goals>
						</execution>
					</executions>
				</plugin>
			</plugins>
		</pluginManagement>
	</build>
	<repositories>
		<repository>
			<id>p2.eclipse.helios</id>
			<url>http://download.eclipse.org/releases/helios</url>
			<layout>p2</layout>
		</repository>
	</repositories>
	<pluginRepositories>
		<!-- At the moment the Fornax plugin is only available as snapshot -->
		<pluginRepository>
			<id>fornax-snapshots</id>
			<url>http://www.fornax-platform.org/archiva/repository/snapshots/</url>
			<releases>
				<enabled>false</enabled>
			</releases>
			<snapshots>
				<enabled>true</enabled>
			</snapshots>
		</pluginRepository>
	</pluginRepositories>
</project>

org.xtext.example.mydsl/pom-grammar.xml

The build of the grammar project needs to execute the workflow src/org/xtext/example/mydsl/GenerateMyDsl.mwe2. All other settings are already managed by the parent.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<parent>
		<groupId>p2.osgi.bundle</groupId>
		<artifactId>org.xtext.example.mydsl.parent</artifactId>
		<version>1.0.0</version>
		<relativePath>../org.xtext.example.mydsl/pom.xml</relativePath>
	</parent>
	<artifactId>org.xtext.example.mydsl</artifactId>
	<packaging>eclipse-plugin</packaging>
	<name>org.xtext.example.mydsl.MyDsl - Grammar</name>

	<build>
		<plugins>
			<plugin>
				<groupId>org.fornax.toolsupport</groupId>
				<artifactId>fornax-oaw-m2-plugin</artifactId>
				<configuration>
					<workflowDescriptor>src/org/xtext/example/mydsl/GenerateMyDsl.mwe2</workflowDescriptor>
				</configuration>
			</plugin>
		</plugins>
	</build>
</project>

org.xtext.example.mydsl.ui/pom.xml

The build configuration of the UI plugin is even easier. Only the reference to the parent and the minimum project coordinates need to be configured.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<parent>
		<groupId>p2.osgi.bundle</groupId>
		<artifactId>org.xtext.example.mydsl.parent</artifactId>
		<version>1.0.0</version>
		<relativePath>../org.xtext.example.mydsl/pom.xml</relativePath>
	</parent>
	<artifactId>org.xtext.example.mydsl.ui</artifactId>
	<packaging>eclipse-plugin</packaging>
	<name>org.xtext.example.mydsl.MyDsl - UI</name>
</project>

org.xtext.example.mydsl.generator/pom.xml

The generator plugin must execute its workflow. Note that the src directory and the compile directory of the grammar project are set as resource directory.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<parent>
		<groupId>p2.osgi.bundle</groupId>
		<artifactId>org.xtext.example.mydsl.parent</artifactId>
		<version>1.0.0</version>
		<relativePath>../org.xtext.example.mydsl/pom.xml</relativePath>
	</parent>
	<artifactId>org.xtext.example.mydsl.generator</artifactId>
	<packaging>eclipse-plugin</packaging>
	<name>org.xtext.example.mydsl.MyDsl - Generator</name>

	<build>
		<resources>
			<resource><directory>src</directory></resource>
			<!-- Add the grammar classes to the classpath -->
			<resource><directory>../org.xtext.example.mydsl/target/classes</directory></resource>
		</resources>
		<plugins>
			<plugin>
				<groupId>org.fornax.toolsupport</groupId>
				<artifactId>fornax-oaw-m2-plugin</artifactId>
				<configuration>
					<workflowEngine>mwe2</workflowEngine>
					<workflowDescriptor>src/workflow/MyDslGenerator.mwe2</workflowDescriptor>
				</configuration>
			</plugin>
		</plugins>
	</build>
</project>

5. Execute the build

Now the build should be executable. Run ‘mvn clean install‘ in the root of the org.xtext.example.mydsl project. Here is an excerpt of the console log you should get. The complete log can be viewed here.

mvn install
[INFO] Scanning for projects...
[WARNING] No explicit target runtime environment configuration. Build is platform dependent.
[INFO] Resolving target platform for project MavenProject: p2.osgi.bundle:org.xtext.example.mydsl:1.0.0 @ /Users/thoms/temp/tycho/trunk/trunk/org.xtext.example.mydsl/pom-grammar.xml
log4j:WARN No appenders could be found for logger (org.apache.commons.httpclient.HttpClient).
log4j:WARN Please initialize the log4j system properly.
[INFO] Adding repository http://download.eclipse.org/releases/helios
[INFO] Adding repository http://download.eclipse.org/releases/helios
[WARNING] No explicit target runtime environment configuration. Build is platform dependent.
[INFO] Resolving target platform for project MavenProject: p2.osgi.bundle:org.xtext.example.mydsl.ui:1.0.0 @ /Users/thoms/temp/tycho/trunk/trunk/org.xtext.example.mydsl.ui/pom.xml
[INFO] Adding repository (cached) http://download.eclipse.org/releases/helios
[WARNING] No explicit target runtime environment configuration. Build is platform dependent.
[INFO] Resolving target platform for project MavenProject: p2.osgi.bundle:org.xtext.example.mydsl.generator:1.0.0 @ /Users/thoms/temp/tycho/trunk/trunk/org.xtext.example.mydsl.generator/pom.xml
[INFO] Adding repository (cached) http://download.eclipse.org/releases/helios
[WARNING] No explicit target runtime environment configuration. Build is platform dependent.
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] org.xtext.example.mydsl.MyDsl - Parent
[INFO] org.xtext.example.mydsl.MyDsl - Grammar
[INFO] org.xtext.example.mydsl.MyDsl - UI
[INFO] org.xtext.example.mydsl.MyDsl - Generator
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building org.xtext.example.mydsl.MyDsl - Parent 1.0.0
[INFO] ------------------------------------------------------------------------
....
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] org.xtext.example.mydsl.MyDsl - Parent ............ SUCCESS [0.681s]
[INFO] org.xtext.example.mydsl.MyDsl - Grammar ........... SUCCESS [26.418s]
[INFO] org.xtext.example.mydsl.MyDsl - UI ................ SUCCESS [3.103s]
[INFO] org.xtext.example.mydsl.MyDsl - Generator ......... SUCCESS [10.844s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

5. Miscalleneous

5.1 ANTLR 3 download

Xtext relies on ANTLR 3, which cannot be hosted at Eclipse.org due to incompatible licenses. Therefore Xtext has introduced an automatic download (FYI: This behavior is implemented in AntlrToolFacade) that you have to confirm once:

*ATTENTION*
It is recommended to use the ANTLR 3 parser generator (BSD licence - http://www.antlr.org/license.html).
Do you agree to download it (size 1MB) from 'http://download.itemis.com/antlr-generator-3.0.1.jar'? (type 'y' or 'n' and hit enter)


Now an automatic build is not so responsive to questions like these. The plugin will confirm this download automatically.

5.2 Workflow execution problems

If the Maven plugin does not execute the MWE2 workflow properly it is not so responsive at the moment to name the root cause. But when running the Maven command with “-X” it will output the full Java command including classpath to the console. Copy the full command and try to execute it from the same directory. This might help to detect the problem you have.

/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bin/java -classpath /Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.xpand/1.0.0.v201006150611/org.eclipse.xpand-1.0.0.v201006150611.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.xtend/1.0.0.v201006150611/org.eclipse.xtend-1.0.0.v201006150611.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.emf.mwe.core/1.0.0.v201006150535/org.eclipse.emf.mwe.core-1.0.0.v201006150535.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.emf.ecore/2.6.0.v20100614-1136/org.eclipse.emf.ecore-2.6.0.v20100614-1136.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.emf.common/2.6.0.v20100614-1136/org.eclipse.emf.common-2.6.0.v20100614-1136.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.apache.commons.cli/1.0.0.v20080604-1500/org.apache.commons.cli-1.0.0.v20080604-1500.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.emf.mwe2.runtime/1.0.0.v201006150446/org.eclipse.emf.mwe2.runtime-1.0.0.v201006150446.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/com.ibm.icu/4.2.1.v20100412/com.ibm.icu-4.2.1.v20100412.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.xtext/1.0.0.v201006170321/org.eclipse.xtext-1.0.0.v201006170321.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.emf.ecore.xmi/2.5.0.v20100521-1846/org.eclipse.emf.ecore.xmi-2.5.0.v20100521-1846.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.xtext.util/1.0.0.v201006170321/org.eclipse.xtext.util-1.0.0.v201006170321.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/com.google.collect/0.8.0.v201006170321/com.google.collect-0.8.0.v201006170321.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/com.google.inject/2.0.0.v201003051000/com.google.inject-2.0.0.v201003051000.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.antlr.runtime/3.0.0.v200803061811/org.antlr.runtime-3.0.0.v200803061811.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.emf.mwe.utils/1.0.0.v201006150535/org.eclipse.emf.mwe.utils-1.0.0.v201006150535.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.emf.mwe2.launch/1.0.0.v201006150907/org.eclipse.emf.mwe2.launch-1.0.0.v201006150907.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.emf.mwe2.language/1.0.0.v201006150907/org.eclipse.emf.mwe2.language-1.0.0.v201006150907.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.xtext.common.types/1.0.0.v201006170321/org.eclipse.xtext.common.types-1.0.0.v201006170321.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.eclipse.xtend.typesystem.emf/1.0.0.v201006150611/org.eclipse.xtend.typesystem.emf-1.0.0.v201006150611.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/ch.qos.logback.classic/0.9.19.v20100519-1505/ch.qos.logback.classic-0.9.19.v20100519-1505.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/ch.qos.logback.core/0.9.19.v20100419-1216/ch.qos.logback.core-0.9.19.v20100419-1216.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.apache.commons.logging/1.1.1.v201005080502/org.apache.commons.logging-1.1.1.v201005080502.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.slf4j.api/1.5.11.v20100519-1910/org.slf4j.api-1.5.11.v20100519-1910.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/ch.qos.logback.slf4j/0.9.19.v20100519-1910/ch.qos.logback.slf4j-0.9.19.v20100519-1910.jar:/Users/thoms/.m2/repository/p2/osgi/bundle/org.slf4j.log4j/1.5.11.v20100419-1106/org.slf4j.log4j-1.5.11.v20100419-1106.jar org.eclipse.emf.mwe2.launch.runtime.Mwe2Launcher /Users/thoms/Development/workspaces/oaw-v5-test/org.xtext.example.mydsl.generator/src/workflow/MyDslGenerator.mwe2

5.3 Fornax Plugin Snapshot version

The Maven plugin org.fornax.toolsupport:fornax-oaw-m2-plugin is not released yet. Yesterday I have added the necessary support for MWE2 and deployed a snapshot version 3.1.0-SNAPSHOT. Some minor issues have to be solved before it will be released.

5.4 Missing log output

The plugin forks a JVM with help of the Java ant task type. At the moment the output from the forked JVM does not get redirected to the Plugin’s log. This is one issue to solve for the Plugin before release. It makes debugging problems a bit harder, but when copying the executed Java command that you get from the debug output and execute yourself you get a better impression of the error.

5.5 Download sources

For your convenience you can download the example project here.

I thought I’d start with the diagram above and add the explanatory text later. But for now, as I hope you can see, I’ve been trying to create a visual summary of these three tech stacks and how they implement different necessary capabilities for user-centric personal information sharing. More later…

Give me a lever and a place to stand and…oh yeah, maybe some duct-tape

When I first saw Intalio’s very excellent case study for Finnair I thought “wow, what a cool idea!” And what a perfect application of SOA technology to solve a very real problem that is forcing a lot of airlines to come up with creative ways of cutting costs.

Being a huge fan of MacGyverism, I then thought about how this application could be improved and how I would implement the solution with just a paper clip, a rubber band and some duct tape - on a much smaller scale, of course. The end result should be nothing short of mildly impressive, considering that this project should cost about $20 in hardware (not counting the cost of an old clunker of a PC which had already been end-of-lifed) and $0 in open-source software. This project, affectionately know as “LaMiPU” (Last Minute Passenger Upgrade) will be the topic of my next several blog entries.

Backgrounder

If you’ve had to fly cross country on a commercial airline lately, you’ve probably noticed that the airplanes are invariably packed to capacity. That’s because in order to remain profitable, airlines must fill all available seats, usually selling the same seat (slightly) more than once at a ratio as high as 1.5 to 1. The seats that sell out less quickly and are sometimes left empty are, obviously, the more expensive business class and really more expensive first class seats because, let’s face it, how many of us regular folk can afford to plunk down $3K for a cross-country flight just for the luxury of a little bit of leg room and a comfy chair. Besides, if an airline overbooks the economy seating section and has to “bump” a couple of passengers to a later flight, there are usually plenty of volunteers willing to make the sacrifice and grudgingly accept a free flight voucher and a free stay at the airport’s red carpet room in exchange for arriving at their destination a few hours (or days) later. If they try to pull that stunt on some muckety-muck, the poor customer service personnel will probably have their ears chewed off.

Pulling ideas out of Finnair

So, as an airline company, how do you avoid flying your airplanes with lots and lots of those really expensive, money making, first class comfy chairs empty and unpaid for? Easy: offer them as “upgrades” (for a “small” fee) to your loyal customers enrolled in your frequent flyer programs; after all, making a little profit on those empty seats is better than making no profit. And besides, this frees up more of your economy seats for potential overbooking. It’s a win-win!

The problem with this scheme however, is that you have to be able to pull this off in a very short period of time. First class no-shows will sometimes cancel their trip last minute (and get a partial, if not full refund for their ticket) leaving the airline holding the proverbial bag. The trick is to offer those seats to your loyal customers who you know will be on the flight because they have already checked in at the ticket counter. This leaves you with a time window of maybe 10-30 minutes to:

1. discover the fact that one or more of your first class seats are empty

2. figure out who has already checked in, and which of those people are enrolled in your frequent flyer program

3. contact those people one-by-one in order based on seniority in the program and offer them the seat upgrade

4. wait for each of those people to make up their minds to either accept or refuse the upgrade; if they refuse, move on to the next loyal customer in the list; if they accept then…

5. pull their credit card information on file, and have them verify it while you still have their attention

6. wait for the loyal customer to fumble around in his/her wallet for the credit card

7. make the credit card authorization; if accepted send the loyal customer verification and somehow make available a new boarding pass in the form of printed or electronic media; if the credit authorization is denied, then go back to #3, lather, rinse and repeat.

Because this process is serial (each customer has to be contacted sequentially because you may only have one first-class seat to offer) it’s doubtful that this strategy would succeed if it were all being done manually. And that is what makes the Intalio solution so elegant.

Oh by the way…if I sound a little bitter, it’s not that I’m begrudging the airlines their profits, it’s just that I’ve been the victim of overbooking and have many times found myself the witless volunteer, accepting a later flight and a voucher (which, by the way, I still haven’t had a chance to cash in on yet )

So now that you have a reasonably good understanding of the nature and complexity of the problem, the next step is to figure out what data resources are already available to be taken advantage of, and which pieces need to be filled in to build a working solution. And that, dear reader, is the topic of my next blog. Stay tuned…

I am happy to announce that the JPA Diagram Editor project made its first milestone release - 0.5 RC1. Just follow the installation instructions, posted on the project’s wiki, and you are ready to build your JPA model in a diagram. There is a nice Getting Started tutorial to help your first steps. If you want to take a quick look before installing, then check our demo on YouTube.

The JPA Diagram Editor is a new incubating project in the WTP Incubator. The project is initiated by SAP and aims to contribute the existing JPA Diagram Editor from the SAP NetWeaver Developer Studio, and continue its future development in the Eclipse community. This contribution is based on the Graphiti project - the new graphics modeling infrastructure in Eclipse.

The official 0.5 version of the project will provide a stable release of the initial contribution. Due to the migration to Graphiti, there are some bugs to be cleaned and we are actively working on them. Nevertheless, we decided to release early to hear your feedback sooner. If you eventually find a bug, then please report it in the WTP Incubator Bugzilla (use component wtp.inc.jpaeditor). You can check the list of already reported bugs if that bug has already been found - we are actively testing at the moment.

Please, note that currently the JPA Diagram Editor supports only JPA 1.0 projects. This mean that you will not see the “Open Diagram” action in the context menu of JPA 2.0 projects. JPA 2.0 support is definitely on our radar screen. We will start working on it after releasing the stable 0.5 version.

Any feedback is very welcome. Especially with suggestions how to evolve the project in the future months. We are available on the WTP Incubator Forum and wtp-incubator-dev@eclipse.org mailing list.

If you are trying to practice Test Driven Development, creating JUnit tests in eclipse can be a real chore at times. I'm not talking about actually writing the tests, but trying to get easy access to the JUnit wizards. The short cuts for creating these types of classes is missing by default from the File->New shortcuts menu when working in the Java Perspective and the Plugin-Development perspective. To enable these shortcuts, you must customize the perspective and go to the Shortcuts tab in eclipse:

I used Declarative Service in my application, JAM Circle.
Declarative Service is cool stuff.
It makes to solve bundles startup order.
But I confused a thing.
How do I inject the service at startup time?
I think services needs to initialize at startup.
So I choosed the way to solve by singleton class like below.

scr.xml
<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="org.kompiro.jamcircle.kanban.ui.KanbanUIContext">
<implementation class="org.kompiro.jamcircle.kanban.ui.KanbanUIContext"/>
<reference bind="setKanbanService" cardinality="1..1" interface="org.kompiro.jamcircle.kanban.service.KanbanService" name="KanbanService" policy="static"/>
<reference bind="setScriptingService" cardinality="1..1" interface="org.kompiro.jamcircle.scripting.ScriptingService" name="ScriptingService" policy="static"/>
</scr:component>

and implementation of Context class(The name inspired from "ApplicationContext")

package org.kompiro.jamcircle.kanban.ui;

import org.kompiro.jamcircle.kanban.service.KanbanService;
import org.kompiro.jamcircle.scripting.ScriptingService;

public class KanbanUIContext {

private static KanbanUIContext context;
private KanbanService kanbanService;
private ScriptingService scriptingService;

public KanbanUIContext() {
KanbanUIContext.context = this;
}

public static KanbanUIContext getDefault(){
return context;
}

public KanbanService getKanbanService() {
return kanbanService;
}

public void setKanbanService(KanbanService kanbanService) {
this.kanbanService = kanbanService;
}

public ScriptingService getScriptingService() {
return scriptingService;
}

public void setScriptingService(ScriptingService scriptService) {
this.scriptingService = scriptService;
}

}

Hi all!

I'm glad to announce to release my RCP application JAM Circle 0.8.0!
Download site
https://sourceforge.net/projects/jamcircle/files/

Project Page
http://kompiro.org/jamcircle

These are New Feature.
* Migrated p2 base Eclipse platform
* Added some Board customize extension point
* JRuby Scripting Console
* improved figures design
* added Japanese resource
* added Eclipes Plug-in Edition
* fixed some bugs

The submission deadline for ESE 2010 is over and there are many many submission. Let me first of all talk about my submissions:

• Adopt the e4 progamming model in Eclipse >= 3.6
  This talk discusses how you can make single sourcing for Eclipse 4.0 and Eclipse 3.6 happen without the use of backwards compat layer coming with Eclipse 4.0
• Can developers adopt e4-RCP for Swing Applications?
  This talk discusses how Eclipse Application Platform 4.0 can be used with other UI-Technologies (e.g. Swing)
• The way to Eclipse 4.0 and 4.1
  In this talk Boris Bokowski and myself will you provide a summary of the last 2 years of on going development of Eclipse 4. Things we achieved, things we failed, things we work on for Eclipse 4.1.
• Eclipse 4.0 Hackfest
  If you want to discuss Eclipse 4 with others and some of the committers on the project. I think this is the right thing for you.

Beside that I’m really amazed by the number of talks who are filed under the Eclipse 4.0 category. What I like most is that the submission are not only from Eclipse 4.0 committers (of course many of them are) but also from early adopters (like The thrill of migrating a mission-critical RCP-application to E4: lessons learned from Jürgen Baier) and framework developers like Christian Campo – Riena on e4 aka “RCP 2.0″ and Matthias Zimmermann & Andreas Hoegger – Eclipse Scout “Querbeet”, tooling provides like Stephane Begaudeau & Jonathan Musset – Acceleo Code Generator, an experimental transition to e4 to people who apply Eclipse 4.0 technologies in none UI-Environments like Gunnar Wagenknecht – Hot e4 stuff for building cool server applications

Along with sponsors including Actuate, BandXI, EclipseSource, Oracle and Open Source for America, the Eclipse Foundation is pleased to announce both the Eclipse Government Day and Eclipse Enterprise Days.

We're organizing two events this fall in Reston, VA. Reston has the convenience of being a mere 15 minutes from Dulles (IAD) airport.

The first event is Eclipse in Government Day. This event is for individuals working for, or contracting with, Government agencies and departments. This is where I could use your help -- if you happen to have any friends or colleagues that are using Eclipse in Government, please do forward a link to the event wiki page or to this blog. This event takes place on Tuesday, October 12th.

The second event is Eclipse in the Enterprise Days. This is a 2 day event (ending 3pm on second day to give people a chance to catch dinner time flights out) and is focused on IT, Architect and Development manager individuals who are responsible for Eclipse in Organizations with hundreds, or even thousands of developers. The agenda on this event is still quite fluid and I have a few folks representing the enterprise helping me shape out the content -- if you have content suggestions, and/or are able to speak yourself, please do let us know! Details are on the events page. This event is Wednesday/Thursday October 13th, 14th.

- Don

With the 3.6 (aka, Helios) release of Eclipse, there is now support for opening files from the operating system command line or file browser directly into Eclipse. This has been a long-standing feature request (one of the oldest requests to ever have been implemented, in fact) and many people are happy to have it. Here is a quick tutorial on utilizing this feature under Mac OS X to associate .java files so that they open in Eclipse upon double-click from Finder. Although this demonstrates using .java files, you can do the same for any other file type; as long as your installation of Eclipse has an editor to handle that file type, it should work just fine.

1. Just to re-iterate, you have to have Eclipse Helios (version 3.6 of the platform) in order to take advantage of this feature. If you don't already have it, go get it.
2. In Finder, locate a .java file that you'd like to open in Eclipse; right-click (or Control+click if that's the way you roll) and select Get Info
   
   
   
   
3. In the Info dialog, under the "Open with:" section, click the drop-down list and select Other...
   
   
   
   
4. Here comes the only tricky part about this process.
   In the resulting Finder dialog to select an application, navigate to where Eclipse is installed. You'll see Eclipse.app listed but chances are, it's disabled; you can't select it. You just have to enable it using the Enable: drop-down list at the bottom of the window, as shown here:
   
   Once you do that, you'll be able to select Eclipse.app.
   
   
5. Before clicking the Add button, decide if you want to select the "Always Open With" option (checkbox). Then click Add.
6. Back in the "Info" dialog, you can use the Change All... button to associate all .java files with Eclipse. Even if you don't do it now, you an always come back to this dialog and do it later.

Eclipse 4.0 brought a great new feature: Theming RCP applications with CSS. Another good news is, this cool feature can also be used with RCP 3.x based applications. The following screen shot shows the RCP Mail Demo, styled with CSS:

How to run the Demo with CSS styling?

1. Checkout :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse/e4/releng
2. Import Project Set /releng/org.eclipse.e4.ui.releng/e4.ui.css.psf
3. Checkout e4/org.eclipse.e4.ui/bundles/org.eclipse.e4.ui.widgets (see bug 322641)
4. Cleanup org.eclipse.e4.ui.css.swt (see bug 322644)
   => Organize Imports
   => Delete dependencies to org.eclipse.e4.core.*
5. Start the CSS RCP Mail demo (project org.eclipse.e4.ui.examples.css.rcp)

The demo also provides dynamic theme switching. Here is is little excerpt from the defaul.css styling:

CTabItem, Label, Tree, Text {
 font-family: "Arial";
}

Shell {
 font-size: 12;
}

CTabItem, ToolBar, Button, CBanner, CoolBar {
 font-size: 9;
 background-color: white;
}

CTabFolder, CTabItem {
 background-color: #F0F1F7;
}

If you would like to play around with the css, just edit the files css/default.css and css/colorful.css in the project org.eclipse.e4.ui.examples.css.rcp. I have submitted a short talk at Eclipse Summit Europe to explain a few more details.

Have Fun!

Kai
Follow me on Twitter

If you like my blog, please feel free to flattr it