Eclipse developers are in the middle of the ‘End Game‘.  Half way through the release candidates and getting ready for another major release.  All the API is in place, the features are ‘complete’ and we are working through the last of the major bugs.

One thing that changes dramatically during the end-game is that each code change requires a review. As we get closer to the release, the number of eyes that must review the code increases.  The theory is that with more eyes on the code, the less likely we are to break something.  It also forces us (the committers) to explain our changes and convince others that the change is really needed. Often just explaining your code is enough to make you see the flaws in it.  Finally, the reviews give us confidence in our changes.

But for a development team that normally does not perform code reviews (at least it’s not part of the mandated development process) the 2 month end-game really mixes things up.

I’m personally  enjoying the code reviews. Of course it gives me more confidence in the code I’ve written (or in some cases I walk away with my tail between my legs), but the reviews are also teaching me a lot.  We all have our own way of doing things.  I have my own coding style; and looking at how others solve problems (and getting feedback on my solutions) is one of the greatest benefits of working on open source.   I view software development as an ongoing learning process, and there is no better way to learn than to critique others and have other critique you.

There are two common methods for reviewing code:

1. Review then commit: The code is reviewed before it is committed to the repository
2. Commit then review: The code is reviewed after it has been committed (and removed or changed if needed)

So my questions to you are:

• Do you find value in code reviews? or are they just a wast of time?
• Have you been involved in open source  or close source code reviews (or both)?
• Which method of code review have you tried? Which one works better?

I have tons of Eclipse workspaces. The last time I counted it was around 24, but it actually changes on a daily basis.

With some of my workspaces I want to have a similar IDE as with others, but some IDEs require special plug-ins. A while ago, as I still unzipped Eclipse-downloads, this was a huge pain. Every time I wanted to work in a specific workspace I had to remember which IDE I used for what, then find the workspace location on the disk, before I could do anything.

Permanent workspaces

Now I double-click a .yoxos file on my Desktop, then start working. Related .yoxos files hang out together on different areas on my desktop. This is possible with the Yoxos 5 Launcher which I explained in my last blog post.

I associate the workspace I want to start in terms of “upper right” or “vaguely in the middle, left” on the screen. No need to remember long directory names.
Remember, a .yoxos file is a definition of both the workspace and the IDE that works on the workspace. The actual workspace is somewhere in my home directory. Since every .yoxos file defines a separate IDE, I always click “Use this as default” after defining the first time where the workspace is located.

Temporary workspaces

Throwaway workspaces go to /tmp. Along with everything else in /tmp, they will be deleted the next time I reboot. The .yoxos file that defines a throwaway workspace should be deleted with it, so this belongs to /tmp as well. The IDE definition works this way:

• Start the Yoxos Launcher
• Add “Project SDK” and all the other desired plug-ins
• Save the .yoxos file to “/tmp/throwaway-workspace” (a new empty directory)
• Hit “Launch”

With the bundle pool I don’t worry about the plug-ins that compose the throwaway IDE. Only rarely something new gets downloaded anyway.

.yoxos files and workspaces

A special handling of .yoxos files in otherwise empty directories supports this workflow. If a .yoxos file is is started while residing in an empty directory, the IDE uses this directory as workspace. This provides an easy answer to the question about the “where”, and I use this feature at a regular basis.

On Mac OS X, I can append the extension “.yoxosws” to a directory that contains a .yoxos file. This defines a workspace that I can start directly with a double-click, without bothering about opening a folder to access the .yoxos file.

Conclusion

The Yoxos 5 Launcher makes it simple to handle a multitude of workspaces. The best thing is that you can stop wondering about the IDE contents and start thinking about workspaces. The Launcher provides a consistent UI to define new IDEs, including a huge number of 3rd-party plug-ins that are not shipped with the default Eclipse downloads.

Tags: yoxos

As I described in a previous blog I’m going to create the tooling for creating equinox based war files within this year’s gsoc. For this purpose I created some UI sketches with the WireframeSketcher. You can see the first thoughts on the UI below. I would appreciate if you can give some feedback on the sketches to improve the tooling. You can find more information about the war products at the wiki page.

• the new wizard

• the warproduct editor

• the export wizard

Tags: eclipseRT, equinox, OSGi, rap, soc, war deployment

I finally had the time to care about one of my outstanding tasks – provide a tutorial and example how to use Equinox Security. While the tutorial was initially targeted for RAP users, I also added a launch config and a target definition for RCP as the code is the same for both runtimes. The tutorial will provide some hints and pointers how to setup your login procedure, like shown below:

After logging in (hint, hint), you’re able to inspect the currently active Subject. I made up this example to be as simple as possible to demonstrate the key concepts of Equinox Security, and not the ones from RAP/RCP.

As I said, you can either choose between RAP as runtime (above) or RCP (below).

In addition to the authentication mechanism, I wrote a pretty simple LoginModule to show how to connect your authentication process to an alternative backend (eg. LDAP, Kerberos, …).

As I put the tutorial into the Eclipse wiki, I encourage everyone to extend the tutorial with hints, tricks or ideas what you can do with Equinox Security. Hope the tutorial helps to get up to speed how to use secure your RCP/RAP applications.

Tags: eclipseRT, equinox, jaas, rap, rcp, security, Single Sourcing

In my last blog I talked about the messaging format which will be used for the RAP protocol messages. I told you that we plan to use JSON as the message format. So, the thing is that the blog ended in a little discussion about what are the benefits of using JSON instead of XML. So, I decided to pick the biggest argument which speaks for XML and try to mitigate it

I want to talk about XML-Schema. XML-Schema is a really great benefit of XML. You can use XML-Schema to describe a XML-Message for validation. Another benefit of XML-Schema is that you can write your schema completely with XML.

When it comes to the discussion why somebody wants to use JSON instead of XML, the schema is always an argument against JSON. But this has now an end. There is a young project out there called JSON Schema. With JSON Schema you can define your message completely with JSON. For sure the JSON Schema is not so well-engineered as XML-Schema at the moment. But I think we need to give it a chance to grow. The guys behind JSON Schema are doing a great job with this technology and are working very hard to make this technology ready for productive use. There are already some implementations of JSON Schema. But enough about the theory, lets take a look at the schema for the protocol message described here:

{
  "description" : "RAP protocol message schema",
  "type" : "object",
  "properties" : {
    "meta" : {
      "description" : "Contains request sepcific information",
      "type" : "object",
      "properties" : {
        "requestCounter" : { "type" : "integer", "minimum" : 1 },
        "settingStore" : { "type" : "integer" },
        "tabId" : { "type" : "integer", "optional" : true }
      }
    },
    "device" : {
      "type" : "object",
      "description" : "Contains display specific information.",
      "optional" : true,
      "properties" : {
        "id" : { "type" : "string" },
        "cursorLocation" : {
          "type" : "array",
          "maxItems" : 2,
          "items" : { "type" : "integer" }
        },
        "focusControl" : { "type" : "string" }
      }
    },
    "widgets" : {
      "type" : "array",
      "description" : "Contains widget specific information.",
      "uniqueItems" : true,
      "minItems" : 1,
      "items" : {
        "type" : "object",
        "properties" : {
          "widgetId" : { "type" : "string", "optional" : true },
          "type" : { "type" : "string", "enum" : [
            "synchronize",
            "multiSynchronize",
            "listen",
            "construct",
            "fireEvent",
            "destroy",
            "execute",
            "executeScript" ]
          },
          "payload" : { "type" : "object" }
        }
      }
    }
  }
}

As with the message itself the most interesting part in the schema is the “widgets” property of the “message” object. It’s very important that it’s an array instead of an object because of the event order which will be send to the RAP server. So, with the JSON Schema we have the possibility to define this property as an array and we can be sure that it’s an array at runtime. Another cool thing is that we can define that all array elements has to be an object with some required properties. For example every widget array element needs a property called “type” for identifying it’s payload. The schema gives us the possibility to define allowed values for the “type” property. So, we can be sure that a message only contains allowed payloads.

I think describing the whole schema will blow up this blog. So, take a closer look at the schema by your self if you are interested and write a comment if something is not clear.

At the moment it’s not clear if we use the JSON schema for the protocol at runtime. But it’s always good to know that we have something for validation. So, let me know what do you think about the schema.

Tags: protocol, rap

Back in the old days, maintaining an Eclipse installation was easy. You just downloaded the Eclipse; it included the JDK and you used this Eclipse on all your workspaces.

But the number of useful plug-ins increased, and many are not included in the downloads from eclipse.org. Developers use different plug-ins in different workspace. For some developers, this leads to as many Eclipse installations as workspaces. Others capitulated and just don’t use many plug-ins even though they see their value; but managing the installations is just too hard. Others again have one huge installation that includes about everything for all the workspaces, and they too have pain with plug-in dependencies. They all suffer from plug-in dependencies.

Imagine you had a system where each plug-in you use is downloaded just once and reused whenever you need it for a new Eclipse IDE.

Yoxos 5 provides that.

Imagine you could just start your workspace and your IDE starts up including all plug-ins you want to work with in that workspace. If it is a new workspace you’d have automatically adjusted predefined settings, import projects etc.

Yoxos 5 excels at that.

Yoxos 5 unifies the workspace settings and its IDE description in a Yoxos Profile. A Yoxos Profile can be defined in a .yoxos file. The Yoxos Launcher creates Yoxos Profiles and starts them, for example when double-clicking the .yoxos file. Plug-ins are downloaded to the bundle pool and started only if the profile includes them.

Yoxos 5 is now in beta phase. You can try it out now:

• Download and install the Yoxos Launcher
• Download and start one of the sample profiles (further down at the download page)

Get more information at http://eclipsesource.com/yoxos5

Tags: eclipse, yoxos

In a previous blog I talked about the functionality that a RAP protocol message should provide. I also introduced you to the requirements of a message. A message should take care about the following tasks: Construction, Destruction, Synchronization, Eventlistener, Events, Methods and Scripting (look at this blog for more details). Additional a message should provide request and display relevant information. So, I decided to search for a messaging format which is able to bring the described information into one message. The result of this search is JSON. JSON is a very lightweight messaging format defined by Douglas Crockford and eliminates the drawbacks of XML. The cool thing about JSON is that it’s really fast to parse a message and it’s very readable by humans. Another cool thing is that it fits all needs of the RAP protocol. So, now lets take a look at a sample protocol message:

{
  "meta" : {
    "settingStore" : 123486875,
    "requestCounter" : 6,
    "tabId" : 4
  },
  "device" : {
    "id" : "w1",
    "cursorLocation" : [ 214, 544 ],
    "focusControl" : "w34"
  },
  "widgets" : [
    {
      "widgetId" : "w23",
      "type" : "synchronize",
      "payload" : {
        "prop1" : "value1",
        "prop3"	: "value2"
      }
    },
    {
      "widgetId" : "w33",
      "type" : "listen",
      "payload" : {
        "selection" : true,
        "focus" : false
      }
    },
    {
      "widgetId" : "w24",
      "type" : "construct",
      "payload" : {
        "parent": "w33",
        "widgetType" : "org.eclipse.swt.Text",
        "style" : [ "BORDER", "FLAT" ],
        "parameter" : [ "eins", 2, true ]
      }
    },
    {
      "widgetId" : "w25",
      "type" : "fireEvent",
      "payload" : {
        "event" : "focus-in"
      }
    },
    {
      "widgetId" : "w26",
      "type" : "destroy",
      "payload" : null
    },
    {
      "widgetId" : "w27",
      "type" : "execute",
      "payload" : {
        "method" : "someName",
        "parameter" : [ "value1" , "value2" ]
      }
    },
    {
      "widgetId" : "w44",
      "type" : "executeScript",
      "payload" : {
        "scriptType" : "text/javascript",
        "script" : "var wm = org.eclipse.swt.WidgetManager.getInstance();"
      }
    }
  ]
}

The above message example shows an imaginary RAP message. The sample make no differences between request and response. Now lets take a closer look at the meaning of the message.

As you can see the whole message is represented as one JSON object. Let us call this object the “message” object. The message object has three properties: “meta”, “device” and “widgets”. Two of these properties are also represented as objects. The “meta” and “device” objects are simple property maps for the request and display specific information. The interesting part of the “message” object is the “widgets” array. As you can see the array is an object array. This means the containing array properties are JSON objects. With the use of an array instead of an object we can bring an order to the containing information which is needed for reproducing e.g. an event order on the server side. Each object in the array represents one widget payload. The payload types map the needed functionality. The following payloads are valid:

• synchronize: For synchronizing widget properties.
• listen: For adding a listener to a client side widget.
• construct: For creating widgets on the client side.
• fireEvent: For firing client side events.
• destroy: For disposing client side widgets.
• execute: For calling a method on a client side widget.
• executeScript: For executing native script code.

Each object in the widget array has three properties. First the “widgetId”. The id is needed to identify the client side counterpart of a widget. The second property is the “type” of the payload (one of the seven above). The “type” property identifies the content of the “payload” property. The “payload” property is normally another JSON object which has “type” specific properties. For example a “widgets” array object of the type “synchronize” holds a map of properties within it’s “payload” object. I think the other types are almost self-explanatory.

I think this is a very straight forward message structure which makes it very easy to understand messages that are sent from the RAP server to the client and the other way around. For sure you have to understand JSON. But I think JSON is very easy to understand and widely used across the web. So, in my opinion JSON is the right choice for the messaging format. With JSON we can completely wrap the required information and it’s free of any meta overhead. Another pro for JSON is very obvious when you look at a message that’s currently sent from the RAP server to the client. So, the described example message is much more meaningful than the RAP generated JavaScript code listed below (normally it’s all in one line).

var wm = org.eclipse.swt.WidgetManager.getInstance();
wm.dispose( "w306" );
var req = org.eclipse.swt.Request.getInstance();
req.setRequestCounter( "3" );
var w = new org.eclipse.rwt.widgets.ToolItem( "check", false );
wm.add( w, "w317", false );
var t = wm.findWidgetById( "w286" );
t.addAt( w, 0 );w.setText( null );
w.setImage( "rwt-resources/35.fwk14856315/icons/ttt.gif", 16, 16 );
w.setSpace( 0, 24, 0, 22 );
w.setHasSelectionListener( true );
wm.setToolTip( w, "Filter all leafs" );

To improve the message quality let me know what do you think about the described format please. Any feedback is very welcome. As a next step I will create a prototype for creating this kind of messages in the context of RAP. I will talk about the structure of this generator as soon as I have results

Tags: protocol, rap

After another 6 weeks of working hard towards the Helios Release, we are one step closer. RAP 1.3 M7 for Eclipse 3.6 is out. From the new features, here are my personal top three:

1. Eventually, a GraphicsContext implementation that lets you draw onto the browser using SWT API! In the early days of RAP, we regarded this as being impossible.
   
2. Animations support in CSS enables cool effects like sliding menus, fading tooltips, and more.
   
3. Vertical-only grid lines make Tables with alternating row colors look much clearer. I had this feature on my todo list for almost one year.
   

• Check out the complete New and Noteworthy for M7.
• Get RAP M7 from the RAP download site or
• Get the M7 Eclipse for RCP/Plug-in Developers package that includes everything you need to develop RCP and RAP applications.

Tags: helios, new and noteworthy, rap

The eclipse planning council has been working hard to come up with a name for next years release train.  To make it as open and transparent as possible, the council took a number of suggestions from the community and put together an on-line poll.  The results were then used to narrow down the choices.

However, it seems that some ballot stuffing has occurred, and the results of the poll cannot be trusted.  The council has added a few security measures to the site and are now re-running the poll.

What does this mean for you?  You have to re-vote for your favorite name.

Please head on over to: http://www.eclipse.org/helios/planning/poll2011name.php and vote again. This time you will have to enter your bugzilla username and password.  It only takes a second, so why not vote now!

Animations are an integral part of most modern UIs, including many “web 2.0″-applications and websites. (Just watch carefully when opening google.com.) They have become so common that we even subconsciously miss them if they aren’t there. The transition between two states of an UI should never be sudden, but gradually (albeit quickly), as we are used from real life. If done right, this increases usability without attracting too much attention or slow down the user. Ideally one isn’t even aware of the effect, it only feels more organic and natural.

Therefore we now integrated the core functionality needed for such animations into RAP. Since the existing client-implementation of RAP was not written with such a feature in mind, it was considerable effort to do this without changing much of the existing code. And for the same reason, there are currently some limitations on what we can do with this feature. However the groundwork is done, and we hope to expand on that in the future.

Just like with gradients and rounded borders before, you can expect the number of supported widgets and effects to grow. You should keep in mind though, that this feature is meant only for subtle animations that seamlessly integrate into the UI. We can and will not turn RAP into some kind of multimedia powerhouse where everything is moving all the time.

For now, “Button”, “Menu”, “ToolTip” and “Shell-DisplayOverlay” each have one effect that can be enabled. This is done using RAPs CSS-theming, not Java, as this kind of animations are mainly eye-candy and don’t add any functionality. The syntax for this is based on a small and easy-to-use subset of the CSS3 working draft for animations. For example:

Button[PUSH] {
  animation: hoverIn 350ms ease, hoverOut 600ms ease-in;
}

This generates a faded hover-effect for buttons.

Animations work on all browser supported by RAP, but might not run smoothly on very old machines. They will be part of the upcoming 1.3M7 build. To see what we can do for now, check out the new “Theming”-Page in our examples-demo.

Tags: new and noteworthy, rap, theming