Here are two ways the Eclipse IP process is discouraging community contributions:

1. IPZilla is private (“committer only”).

Why? I find this intransparent and discouraging towards contributors. At a minimum it should be open to committers and contributors.

2. IPZilla round-trip times for small contributions are way too long.

I think a speedy round-trip-time for small contributions (i.e. few days) is paramount in making it worthwhile for the community to contribute AND for us committers to shepherd these contributions.

To illustrate my point: I’m waiting more than two weeks for a CQ to be approved, which I could write myself 2-3 times in those two weeks. Should I turn the next contributor away? (“Thanks, but it’s faster if I write it”)

I wonder why can’t non-incubation projects in good standing have parallel ip for their milestones?  This would speed-up acceptance of community contributions. The review could be completed in the ramp down time between freeze and final release.

What do you think?

PS: kudos to the Eclipse legal team for doing a great  job making Eclipse technology commercially consumable.

Tags: eclipse, ipzilla, rant

With e4 0.9 out in the wild, we should think again about the goals e4 tries to provide. One of them was to reduce the gap between Desktop and Web – not only speaking of reusing widgets but also to enable the platform handle multi-user scenarios. While the core e4 team concentrated on eliminating bad smells like singletons, the RAP team worked on better support for single sourcing applications in general. With an experimental version of RAP which includes some features not yet in the current release, we were able to run the demo out of the box including the whole underlying infrastructure like the modeled workbench – without touching the e4 code.

If you take a look at the RAP Demos page you’ll find the e4 contacts demo running on RAP. If you want to try it out yourself or even help to contribute to this effort, take a look this wiki page. In case you’re interested what you can do with e4, be sure to participate in the e4 webinars.This week, there will be Part 2 with topics like RAP, the Compatibility layer and the flexible resources model. Looking at the questions that came up in the last RAP webinar and the first part of the E4 webinar, people seem to be very interested how e4 and RAP play together. I’ll try to answer the open questions during the webinar this week. Looking forward to a great event.

Tags: databinding, e4, rap, Single Sourcing, swt

I spoke with a Rich Ajax Platform (RAP) committer briefly today and he reminded me that the RAP team recently released 1.3 Milestone 1 to the world. This release marks the first milestone towards the Eclipse Helios release and includes some interesting features like rounded corners, gradients and support for cheatsheets.

For those people interested in single sourcing their Eclipse RCP applications, they will be pleased to see support for more RCP APIs in this RAP release. Check out the new and noteworthy for more detailed information. Also, the RAP team published the project plan for 1.3 with suggested and committed items for this release. If you have any additional input or questions on the plan, feel free to discuss them with the team on the RAP mailing list.

Tags: rap

The Fellowship of Riena just released 1.2.0.M1. (download). We committers have fixed 40+ issues and added a couple of new features. Below are my personal favorites.

Improved support for message markers. Multiple validation rules and validation messages are now shown correctly (snippet):

The new IListRidget simplifies binding to  lists of elements with one column. This is a bit simpler than using a ITableRidget (snippet).

Easier listening for selection changes using an ISelectionListener on ITableRidget, IListRidget, ITreeRidget, ITreeTableRidget, ISingleChoiceRidget, IMultipleChoiceRidget.

Better keyboard navigation. We have added several new shortcuts. Some examples:

• Next / Previous navigation element – Up / Down in the navigation tree
• Next / Previous Module – Ctrl-Down / Ctrl-Up
• Next / Previous SubApplication – Ctrl-PgDn / Ctrl-PgUp
• Close Module / ModuleGroup – Ctrl-W / Ctrl-Shift-W
• Focus on Navigation / Workarea – F6 / F7
• Focus on Window Menu – F10 (windows only)
• Quit Application – Alt+F4 (windows only)

and  SubApplication titles now support mnemonics for easier access via the keyboard:

Here’s the complete New & Noteworthy.

Kind regards,
Elias.

PS: SubApplication, Module, ModuleGroup are explained here.

Tags: eclipse ui, helios, milestone, riena

This Thursday, Google is graciously hosting an EclipseDay At Googleplex. There will be talks on topics like Distributed OSGi, Eclipse at NASA and Android. Here’s a peak at the full schedule:

If you’re interested in attending, the registration list is already full, however, there is a waiting list you can signup for. If you can’t attend, don’t worry as Google is planning to record and release videos of the presentations. Also, from the EclipseSource team, Scott Lewis and I will be there so if anyone is up for frosty beverages, please let us know!

Tags: eclipse

Starting out with Eclipse Riena?  I hope you find my one-picture-summary of the Riena UI and navigation useful:

Conceptually the window is divided into the navigation tree on the left - showing a navigation model – and the work area on the right - showing the view that is currently active. Other window areas are the menu bar, the coolbar and the status bar.

The navigation tree shows the navigation model of the current SubApplication and can change during run-time (for example elements can be added / removed). Conceptually it is a tree constructed like this:

1 Riena Application  - root of the navigation tree; non-interactive
> 1-n SubApplications – each sub application has a clickable tab in the top part of the window
>> 1-n ModuleGroups – groups several modules together; non-interactive
>>> 1-n Modules – has a title (blue background) and 1-n SubModules
>>>> 1-n SubModules – is associated with a View and Controller. When a SubModule becomes selected the corresponding View is shown in the work area. SubModules can be nested. If module has just one SubModule it is not shown.

As you can see, Riena steps away a bit from perspectives, views, editors in favor of a task oriented interaction (side note: underneath this we use views and perspectives, and we support integration of regular views). For example you could have a SubApplication called “Customers”, with a Search Module and additional Modules for each of the customers you are currently editing:

For the full details read the excellent ‘Riena Navigation‘ page on the Riena wiki. The wiki explains this in more detail and shows how to create the navigation structure through Java code or the plugin.xml file.

Tags: eclipse ui, riena

The Linux Foundation just published a report with metrics about who and how much is contributing to the Linux kernel. As an Eclipse committer I found this insight into the kernel ecosystem fascinating. Below are couple of data points that got my interest.

Comparing kernel development over the last year (release 2.6.30 with 2.6.22):

• development speed is increasing (patches per release: 50-100% up, lines of change per day: 100% up to 20,000 from 10,000 a year ago)
• kernel size is increasing (+35%, 11.5m LOC vs 8.5m)
• number developers  going up (+32%, 1,150 vs 870)
• number of involved companies going up (+33%, 240 vs 180)
• constant release rhythm of about 12 weeks/release – despite the increases
• focus on commerial development (74,2% done by paid contributors, 18,2 % by non-paid contributors, 7,6% unknown)

Two things that impressed me:

• the ability to keep release speed constant, despite a huge increase in contributors, patches and lines of code changed
• the amount of diversity within the kernel community. The overall top-10 contributors (page 11)  amount to 66.7%.  As of today the 2009-top-10 contributors by LOC at Eclipse.org amount to 92,09%  (dash). So it looks like the weight of the kernel development is better distributed. Note, these are only 2009-YTD contributions.

What did you find interesting or impressive?

Tags: eclipse, linux, Open Source

In part 2 of this blog series, I described how to use Equinox p2 to install a new feature into a running Equinox application server. Rather than do this install at runtime via the OSGi console, many times it’s desirable to add bundles to an application server statically at build time rather than at runtime.  For example, this is usually the case when adding libraries for your web application to use. These libraries are sometimes created by others and sometimes created by you.

This post will go through a simple example of how to add your own bundles to your Equinox application at build time.

First, let’s return to the workspace that we setup as described in the first post in this series.  Here’s what the workspace should look like after completing steps 1-4 of the first post:

To add sets of bundles to the target application server, we create a new feature for grouping the bundles.  A feature project is created through the new project wizard via menu selections New Project->Other…->Plugin Development->Feature Project.  I’ve created a new empty feature called com.mycompany.myappserverfeature, but it can be called anything you like:

Then choose the Plug-ins (otherwise known as bundles) tab in the feature editor and you can add bundles to be included in your new feature.  The bundles that appear in the dialog when selecting Add… will include all the bundles in your workspace, as well as all bundles currently included in your target platform.  For a description of how to add to your target platform, and an explanation of what you can do with the target platform since Eclipse 3.5 please see the Improved Target Platform Management blog post.

I’ve also added some bundles in my target platform that support doing ECF remote services with the r-OSGi provider.   This enables support for remote OSGi services between application servers (i.e., having one server call a remote OSGi service exposed by another server).

After adding the bundles you wish to include, save the changes to your feature and then add your new feature to the equinox-milli.product. Features can be added to the equinox-milli.product on the Dependencies tab of the equinox-milli.product editor.

Here’s the Feature Selection dialog that appears when you select Add… on the Dependencies tab:

And then you will see your com.mycompany.myappserverfeature listed as part of the equinox-milli.product:

Save the changes to the equinox-milli.product and then you can go to product editor Overview tab, select the Eclipse Product export wizard (in lower right of Overview tab) to display the export wizard dialog:

You can now click Finish and do exactly the same things as described in steps 6, 7, 8, 9 in the original post to create a zip file (e.g., named myappserver.zip), rename it to myappserver.war and then hot deploy the new war file to your servlet container of choice to run it.

Once running, at the osgi> prompt you can convince yourself that the added bundles are now present in your application server by typing ss and looking for the bundles added by your feature in the resulting list:

As you can see, these bundles are in place and ready to use from within your web applications!

Tags: ecf, eclipse, equinox, OSGi, p2

In my previous post, I described how to easily build an Equinox-based web application server that can be run on any servlet container. Note that in the previous post I had these instructions for completing the export wizard dialog

d) The Generate metadata repository should be unchecked

If using p2 (as in this post), this is incorrect.  It should say

d) The Generate metadata repository should be checked (to include p2 metadata)

I’ve updated this documentation in the original posting.

Once your p2-enabled app server is running, you can do some really cool things with it.  For example, since p2 is available, you can dynamically install new components into your running application server.  Here’s the OSGi console help output (part of it anyway):

Notice the Provisioning Commands text.  These are console commands enabled by the presence of p2 that allow you to do common provisioning operations like installing new components.  In this blog entry, I’ll show how to install a version of the Knoplerfish httpconsole, but the same approach applies to software available from other p2 repositories.  In other posts, the EclipseSource team will show how to do this hot deployment into a running server for:

• RAP
• ECF
• Other EclipseRT Project components

First, one must add the metadata and artifact repository URIs using the provaddrepo and provaddartifactrepo commands:

Notice the provlg command, which lists the p2 groups available in the newly added repositories (in this case, the Knopplerfish httpconsole v2.0.0).  Now, issue the provinstall command with the feature group and version… wait a few seconds and you should see the install complete message

Then issue the confapply command (this command applies the new bundle configuration to the currently running platform):

Now, you can see the new bundle installed via the short status (ss) command:

To start the httpconsole bundle (and activate the servlet that it runs) just type start 50.

At this point, you can open a web browser, and point it at your Equinox application server now running the httpconsole at http://localhost:8080/myappserver/console and magic…your application server is now running the Knoplerfish httpconsole servlet, which provides a web interface to the list of running bundles:

Just for fun, you can stop the httpconsole with stop 50 and the servlet will no longer respond

You can start it back up, and then the servlet will be running again. This makes a nice demo for people that have to manage the install and update of new components into a running application server. In future posts, I’ll show how to add features to your application server statically (during the build, rather than at runtime) as well as how to use ECF remote services to manage a running application server without having to use the OSGi console.

Enjoy!

Tags: ecf, equinox, OSGi, p2, rap

Dynamically typed programming languages have become more popular over the recent years. Dynamic typing makes certain tasks a lot easier, however, I will not go into a full discussion of dynamic versus static typed languages (I’m saving that discussion for later). Instead, I want to take a look at one of the cool ideas in dynamic language design and demonstrate how Eclipse can somewhat emulate it.

By definition, dynamic languages have no concept of variable types. This means there is no need for a type declaration… so for example, in Python or Ruby you can just write:

randomNumber=4

Some statically typed languages also allow the type declaration of variables to be omitted. But since the language is statically typed, where the does the variable type come from? A reasonably smart compiler can infer the type of a variable by looking at how the variable is used. Haskell and Scala are two examples of such languages that allow implicit typing and then determine the types through compile time type inference. This allows you to write the following scala code:

var randomNumber=new BigDecimal(4)

The type of randomNumber is java.math.BigDecimal. This avoids having to type BigDecimal twice… once for the variable type declaration and once for the constructor. Since Eclipse has a full blown Java compiler under the hood (a fairly smart one), it allows you to do almost the same. You can basically omit the type declaration altogether, and when Eclipse complains just, hit Ctrl+1 and select the appropriate option. The official name for that shortcut is Quickfix, but I like to think of as: “Dear Eclipse, I’m just too lazy, why don’t you fix it for me?”

I don’t know whether this quickfix was created with this usage pattern in mind, but I find myself using this quite often. A close relative is the Extract variable refactoring which also does design time type inference. Another refactoring where type inference comes into play is Generalize declared type, which lets you reduce the specificness of a variable type to its lowest common denominator.

I am sure there are a number of similar refactorings and quick fixes. These powerful features demonstrate how a smart IDE can make working with a statically typed language much easier, while still reaping the benefits of static type checks.

What are your favorite type inference shortcuts?

Tags: eclipse, implicit typing, jdt, type inference