As Galileo is out in the wild and we are all already working on Helios… I thought it would be handy to give a quick overview of the New and Noteworthy features the RAP team worked on for Galileo. Besides many, many bug fixes… we still found time to provide several new features. On top of the new features, we focused on making single sourcing even easier to do.

New Look and Feel

This is one of the biggest features of RAP released as part of the train. As Ian already pointed out correctly:

One of the common complaints about RAP was that it doesn’t look like a web application.

While this was true in the past, we worked really hard to provide the community a clean and easy way how to customize the whole workbench styling.

Cell Editors

It’s finally done – RAP supports cell editors in the Table. As this was a really long-standing issue we’re more than happy to have it in 1.2.

Ed, now it’s time to give the whole “generated EMF editor on RAP” idea a new spin! For anybody interested in this story, please CC yourself on this bug.

Performance & Memory

The RAP team really had a great time for this release – we just sat there and waited for the browsers to become even faster…as this was a really silly task we decided to do something:

Improvement of Session Startup Performance

First the creating of the startup page is less CPU intensive. Second the javascript library content is not embedded in the startup page anymore and will be delivered separately. As the library content doesn’t change after server start it can be zipped once and buffered. This reduces CPU usage significantly. The library is stored in the browser’s cache and need not to be reloaded on subsequent application visits.

Client-side memory improvements

Included is also a new version of the Javascript library qooxdoo. Thanks to the great support by the RAP community, most notably from Stefan Hansel who tracked down a number of significant memory leaks in qooxdoo and provided patches to the qooxdoo developers, this version now brings a major improvement in client memory consumption. With this qooxdoo version, the long-standing memory leakage problems of RAP especially in Internet Explorer are resolved. Thanks to everyone who helped making this possible!

New API & Widgets

With the idea of single sourcing in mind we concentrated on adding new API to allow even more reuse of existing SWT/RCP code. Besides many small things like Display#timerExec() we also tried to complete the set of widgets. With 8 (yes, eight) new widgets in this release, these two are my personal favorites and often requested by the community.

DateTime

FormText (Forms)

Cursor Support

Summary

In case you’re not yet sure how “single sourcing” works – Ralf and Rüdiger would be happy to explain it to you step-by-step in their upcoming webinar.

In summary, we’re quite happy with the current 1.2 release but are already looking forward to the Helios release train.

If you have anything you want to see in 1.3, don’t hesitate and drop us a note.

Tags: api, eclipse rap, galileo, memory, new and noteworthy, performance, rap

As part of the Eclipse Galileo release, we updated all of our training courses to reflect the latest release:

• Eclipse RCP Development (4 Days)
• Eclipse RCP Advanced Topics (3 Days)
• OSGi and Equinox (3 Days)
• OSGi and Equinox Primer (1 Day)
• RAP for Java Developers (4 Days)
• RAP for RCP Developers (2 Days)

We have also added two new courses to cover two popular topics, Equinox p2 and migrating to Galileo RCP:

• Provisioning Eclipse and OSGi systems with p2 (2 days)
• Migrating to Galileo RCP (2 days)

We are also offering our courses online now. If you’re interested in any of these courses, please email us.

Tags: galileo, OSGi, p2, training

In his posting All contributions are Equal, some are more equal than others, Robert Konigsberg points out that contributing multiple ways of doing things can easily lead to more user complexity (e.g., by having multiple toString generators).

This is true and in my view, a risk for any system that has many strongly-opinioned contributors (pretty much any large open source project).

Toward the end of his post, he poses a process-level question about how to avoid the situation of some contributions being more equal than others…. I think the solution is the current de facto for Eclipse.org projects and that’s the (frequently unstated) reality that the early bird defines the worm.

When it comes down to it, those that initiate and then follow through on enhancements, fixes, documentation or other contributions get to choose when it comes to actual design decisions. Inevitably, there are design choices that some disagree with, even when all discussion is had completely in the open.

I think the truth of the early bird defines the worm statement is that we should provide incentive to organizations and individuals in the community to be more aggressive about contributing to existing Eclipse projects. This is because  waiting for someone else to initiate, design, implement, test and document something often doesn’t work very well.

To some, it may seem like Eclipse Project development is effectively subsidized by others, but this is not true.  Even for one’s own usage of Eclipse, contribution and community involvement with Eclipse.org projects pays dividends. There are many ways to contribute, from contributing discussion/ideas, to planning, to new example/app code, to helping to maintain existing code, to documentation, to build support, to testing and bug reporting, to providing bug fixes, to mentoring, and plenty of other kinds of support.

In my view, these are the ways to get your contributions into Eclipse, and influence the community around the software.

Here’s my understanding of where the toString() contribution originated.

Tags: eclipse, projects

We’ve added to our distributed OSGi documentation (with examples+source) for ECF 3.0/Galileo:

• Distributed OSGi Services with ECF
• Getting Started with ECF’s RFC119 Implementation
• Getting Started Using the ECF Remote Services API

We have API layering so service programmers can choose the simplest appropriate mechanism for their system requirements, while still providing access to ‘lower-level’ concerns when necessary:

• failure handling
• synchronous vs. asynchronous remote method invocation
• serialization and wire protocol
• and so on…

If you have any questions or comments, please let us know on the ECF mailing list.

Tags: api, ecf, eclipse, equinox, OSGi, rfc119

Twenty-four hours after opening the flood gates and releasing Galileo I thought I could provide some statistics. Over a year ago I started one of my talks at EclipseCon announcing that every 3 seconds someone starts a download of a packages that we create in my Eclipse Packaging Project.

But everything is different in the first few days after a release. When I checked the download page and the download counter I calculated that there were about 100000 downloads of the packages (including the ‘classic’ SDK). This means that every 0.9 seconds a package has been downloaded! Cool. Just a few more numbers:

• Java EE package with more than 50000 downloads so far
• Total amount of data (all packages): More than 15 TBytes (15000 GBytes!)
• Average bandwidth necessary to serve this data: 1600 MBits/s

Then I checked the logfiles of our own EclipseSource servers. In addition to our download mirrors we decided this year to provide package downloads from the Cloud. Maybe you have seen then new download links to Eclipse members on the download page:

If you choose our “Get It Faster Here” offering you are downloading the packages from Amazon Cloud Front. It is hard to say how many people were using this service in the first 24 hours, because many people were using download managers (something that prevents me from providing exact numbers based on the logfiles). But what I can provide here is a statistic about the download speed in MBits per second:

You can see that most people are sitting behind Internet connections that can deliver 5 to 20 MBits/s, but some have really fast pipes. For example, I was testing our downloads from a large research facility here in Germany and I got a download speed of more than 280 MBits/s!

I think that’s great. You don’t have to wait for downloads any more!

Tags: eclipse, epp, galileo, p2

As we learned from Ian Bull, p2 has come a long way for the Galileo release.

Now that Galileo has shipped, a lot of the Eclipse development teams are going on vacation or starting the planning process. In particular, the p2 team is looking for ideas on how to improve the user interface in Eclipse 3.6 and Helios.

If you have any problems with the current user interface or would like to see some enhancements, please comment!

Collaboration in open source is a two way street!

If you aren’t convinced that your feedback matters, just asked some of the people that the p2 team thanked on the Eclipse 3.5 acknowledgements list.

Tags: equinox, OSGi, p2

I like to keep my desktop pretty.

Support the Eclipse Galileo release by grabbing some new desktop wallpaper!

1600×1200
1680×1050

Thanks Nathan Gervais!

Tags: galileo

Today is the big day! Eclipse 3.5 – Galileo – is available for the general public. To count down the final push towards Galileo, I have been reviewing the Top 10 features that I’m most excited about. There are tons of other great features – such as the SWT port to Cocoa – that I personally don’t make use of, so if you disagree with my Top 10 list, I encourage you to publish your own.

A quick recap of what I have reviewed so far:
10. Enhancements to the Java compare editor
9. Improved Java 2 Javascript Bridge
8. The new RAP Look and Feel
7. EMF Ultra Thin Diet
6. Install into self
5. Memory Analyzer Project
4. Mylyn Wikitext
3. Improved Target Platform Management
2. OSGi Declarative Services

And without further ado, the Number 1 Galileo feature (according to me) is – p2, Round 2.

The Eclipse provisioning platform (p2) was originally released as part of Eclipse 3.4. At the time it provided a solid replacement for Update Manager, with the scaffolding in place to enable it to be a true provisioning platform. As of Eclipse 3.5, I can say that p2 is now a full fledge platform for provisioning everything and nothing in particular.

During the past year, p2 has been updated and improved in a number of different areas. New features were added, over 1,000 bugs were closed, workflows were revamped and even the helpful error messages were improved.

The uber-talented UI designer – Susan F. McCourt – reworked the entire p2 workflow. The repositories lists have been updated, the installed software views received a face lift and the “Install New Software” wizard has been completely revamped to support a more asynchronous user experience. Susan also provided a number of extension mechanisms so you can make use of the p2 UI in a number of different ways within your own RCP application.

Jeff McAffer designed the publisher, a new mechanism for writing repositories. The publisher provides a flexible method for working with p2 metadata. Andrew Niefer – the workhorse behind PDE Build – provided a lot of the publisher polish, and even re-worked PDE Build to use this new technology.

Henrik Lindberg contributed “Chester the test-data molester” an environment that helps test p2 using a variety of error scenarios. Using this, p2 can be tested against network problems, invalid modify dates, invalid file sizes, endless redirects, etc… Henrik also worked extremely hard on p2 transport layer. Below the transport layer, Henrich Kraemer, Scott Lewis and the ECF team provided a new provider based on the Apache httpclient.

In the p2 planner, the part that actually computes what needs to be installed, Daniel Le Berre – as part of his research studies – improved the explanation support. This means instead of getting a long winded explanation when you try to install conflicting bundles, you get a concise error message outlining the root of the problem.

DJ Houghton provided bug fixes all over p2 including many of invaluable tools such as mirroring, the director, the p2 garbage collector and the publisher.

One of the coolest features – meta requirements – was implemented by Simon Kaegi. Using meta requirements you can now ship the code to help install your software, along with your software.

John Arthorne helped a number of contributors earn their commit rights by providing true mentorship and advice. Additionally, John managed to fix a few hundred bugs, implement composite repositories, cleanup the p2 metadata implementation, fix a number of p2 caching problems, and generally improve the scalability and performance of p2.

While everyone worked very hard, the biggest kudo for p2 goes out to Pascal Rapicault, the p2 team lead. Pascal knows p2 inside-and-out and managed to assemble an excellent provisioning platform despite the occasional poorly worded bug report. Great job Pascal!

Next year’s project planning is starting now. Personally I would love to see even better scalability (client – server repository models), improved repository tooling and tighter integration with the target platform management.

Thanks for everyone on the p2 team, and all committers, contributors and users who made the Galileo release possible.

Enjoy the rest of the day, and tomorrow everyone should be back at work on Helios.

Tags: equinox, galileo, OSGi, p2

As many people have already said, Galileo is available for Friends of Eclipse. As Chris pointed-out, one of the reasons Eclipse is able to ship quality software, consistently on-time, is because of the modularity offered by OSGi.

Using OSGi, developers are able to work independently on their piece and the final product assembled separately.  In addition to the componentization, OSGi enables lazy loading. Each bundle can contribute “services” and the bundles are only activated if the services are used. This means that an embedded OSGi application (with 10 bundles)  feels as responsive as a fully featured IDE with over 1,000 bundles. This lazy, service based, programming model is extremely powerful, however, very hard to get right. Eclipse 3.5 has completely changed this by making OSGi Declarative Services a first class citizen– Number 2 On My Top 10 List of Galileo Features.

Declarative Services (DS) is an OSGi specification to make it easier to wire services together across bundles.  Using DS, developers can specify what services their bundle provides and what services are required.  This is all specified “declaratively” using XML, and the DS bundle is responsible for wiring everything together.  Huge kudos go out to ProSyst for this work, with special thanks to Stoyan.

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" 
      name="Command Provider for Dictionary Service">
   <implementation class="org.example.ds.ServiceComponent"/>
   <service>
      <provide interface="org.eclipse.osgi.framework.console.CommandProvider"/>
   </service>
   <reference bind="setDictionary" cardinality="1..1" 
      interface="org.example.ds.DictionaryService" 
      name="Dictionary" 
      policy="static" 
      unbind="unsetDictionary"/>
</scr:component>

In the example above, this particular component provides a “CommandProvider” and requires a single instance of the “Dictionary Service”.  The Dictionary service is provided in the bundle activator using the Service Tracker:

// register the service
context.registerService(DictionaryService.class.getName(), service, props);
 
// create a tracker and track the service
dictionaryServiceTracker = new ServiceTracker(context, DictionaryService.class.getName(), null);
dictionaryServiceTracker.open();
 
// have a service listener to implement the whiteboard pattern
fContext.addServiceListener(this, "(objectclass=" + Dictionary.class.getName() + ")");

When launched, assuming both the Command Provider and the Dictionary are available, the user can look-up a word using the OSGi console:

Like many of the best Eclipse run-time technologies, the Eclipse tooling is what catapults it into the mainstream.  In Eclipse 3.5, the Bundle Development Environment (PDE) introduced top notch tooling for working with DS. Using the DS tooling, you can craft component.xml files using a form based editor.  A big thank-you goes to Chris Aniszczyk and Rafael Nobrega for the tooling.  Rafael was a Google Summer of Code student!

As well as an excellent Run-time and top notch tooling, Chris also put together a template to help you get started.  Simply select New Plug-in Project, and choose the OSGi Declarative Services Example.

Eclipse continues to lead the way by providing Open Source, reference implementations, for a number of key specifications. By providing open implementations, organizations benefit by:

1. Sharing the development cost
2. Having a very large user base test their implementation
3. Having a very large user base exposed to their technology
4. Having a variety of different people (with different background) contribute to the work

For more information on DS and OSGi in general, checkout the new book by Jeff McAffer, Paul VanderLei and Simon Archer.

Thanks to ProSyst, Chris, Rafael and everyone else who worked on this implementation.  Another shining example of the win-win situation enabled by open source software development.

Tags: galileo, OSGi

Ah, Eclipse Galileo is finally out for Friends of Eclipse, I just got the glorious email:

If we look at the annual releases of Eclipse, we have some nice consistency:

2004 – June 28th (Eclipse 3.0)
2005 – June 28th (Eclipse 3.1)
2006 – June 30th (Callisto)
2007 – June 29th (Europa)
2008 – June 25th (Ganymede)
2009 – June 24th (Galileo)

Can’t say that about many software projects as large as Eclipse!

With Eclipse releasing at the same time every year, I can say with confidence that we’ll see the next annual release of Eclipse (Helios) on June 24th, 2010. But why do this every year? Why get a bunch of independently run projects to release together?

Well, I think it’s simple… it helps spur the adoption of Eclipse technology. The consumers of Eclipse technology use many projects, not just the “Platform” projects so having the ability to get them at once is a good thing. Essentially, the latency between independently run projects is removed by having an annual release train. Another interesting benefit of having an annual release is that it allows for alignment of version compatibility which is hard to get right. There are many other reasons, but the important thing in my opinion is seeing many developers united around platform and building cool technology with it.

In the end, I’ve convinced myself that having these large annual releases of inter-dependent but independently run projects is only possible because of OSGi and modularity. OSGi allows for fences (API contracts) to be built around useful bits of functionality. As the saying goes, good fences make for good neighbors… and for good release trains.

Enjoy Galileo and see you next year for the Eclipse Helios release !

Tags: OSGi