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

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.

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

Software development can be characterized by the management of two separate, yet equally important groups of artifacts. The source code you write and the libraries you depend on. Much of our education, tooling, and software engineering literature focuses on the first part – this post focuses on the second.

The Eclipse Galileo release is almost here, and for the past week I have been counting down the top 10 features I’m most excited about. The features come from a variety of different Eclipse projects including the Platform, Modeling, Runtime, Tools and Technology. Some of the features I’m excited about help teams of developers write better code, or exciting new plug-ins, in a more productive manner. Other cool new Galileo features provide developers with a more streamlined, feature rich, API. Number 3 on my Top 10 list — Improved Target Platform Management — bridges the gap between these two groups.

Targets platforms define what your workspace will be built and launched against. By defining your target you can easily use one version of Eclipse for development, while targeting a different version for your product. Many developers simply download Eclipse, create a new plug-in project and start hacking away. This approach can lead to a number of problems:

1. What if you want to update your tooling (to use a new version of Ecore tools), do you want your product built against this the new tooling?
   
2. What if you don’t need GEF based tools but you wish to make use of GEF in your product. Do you want GEF “installed” in development environment?
3. What if you work in a team. Do you require that your entire team uses the same version of Eclipse for their development?
4. How do you change the libraries you depend on?

By managing your targets, you are free separate your development environment from the software you are building. You can even share your target definitions with team members.The Galileo release brings a number of improvements to the management of target definitions, including:

Target editor enhancements:

A new target platform preference page:

A target platform state view:

Software site target provisioner:

Let’s step through a very simple example.  Let’s say you have Galileo installed and you want to build a product based on EMF.  Instead of installing EMF, you create a new target definition, add a “Software Site”, and choose EMF from the Galileo repository.  EMF (and its requirements) will fetched and added to your target platform, but it is not installed.  This means you can upgrade your tooling (or even install a different version of EMF tooling) without affecting the software you’re building.

You can even have multiple targets with different versions of EMF and using the Target Platform preference page, you can switch between them.

Kudos for this feature goes out to the PDE Team. In particular, Darin Wright, Curtis Windatt and Chris Aniszczyk!

Awesome work guys!

Tags: galileo

As I mentioned yesterday, tools such as the Memory Analyzer demonstrates just how dominant Eclipse is in the IDE space. And while Eclipse has many useful tools, nothing has changed the face of the IDE as much as the Mylyn project. Mylyn is more than just a cool plug-in for Eclipse, it completely changes the way developers work, bringing your productivity to a whole new level.

On the way back from EclipseCon, I had the privilege of sitting next to David Green, one of the Mylyn committers and the developer behind the Mylyn WikiText tool, number 4 on my Galileo Top 10 List.

Like all good Eclipse technology, Mylyn WikiText is both an extensible framework and an exemplary tool. The tool provides:

• Editor for wiki files
• Mylyn task editor integration
• Ant Tasks for processing wiki text file
• API

The Task Editor integration is probably the most noticeable use of WikiText. Mylyn users can now use WikiText markup directly in their task editor providing easier to understand bug reports.  For example, you can take a rather bland bug report:

And turn it into:

In addition to the markup, Wikitext supports a number of editing features including spellchecking, and content assist.

David’s Wikitext tool can be used outside Mylyn too to author arbirary text file and generate HTML, Docbook or eve Eclipse help content.

In addition to Wikitext, Mylyn has a whole host of new features. Thank-you David for Wikitext, and congratulations Mik and the rest of the Mylyn team for another successful release.

Tags: galileo

With all the great work going on in the Eclipse Run-time space, like the EMF Runtime, RAP, Birt Charting Engine, ECF, Jetty and of course Equinox, I sometimes forget that Eclipse started as an excellent platform for tools. The Eclipse Memory Analyzer project reminded me just how good Eclipse tools are.

All week I have been counting down the top 10 Galileo features that I’m most excited about. Number 5 on my list is the Eclipse Memory Analyzer (MAT). This project was first released in December 2008 and is now part of the Galileo release train. MAT provides a large selection of features to help you analyze Java heap dumps to understand your memory consumption and help remove leaks.

As you may have noticed, many of my posts focus on the simplicity of the new features. The MAT project is no different. Getting started with the Memory Analyzer is a simple 3 step process:

1. Install the MAT tools (optionally install the charting engine too). (Hint: Use p2 for this)
2. Grab a heap dump:I simply used the JMap tool available with my JDK. 12345 was the PID of my Eclipse process.
   $ jmap -heap:format=b 12345
3. Open the Heap Dump
   JMap generates a file called heap.bin

Some of the notable features include:

The reporting of memory leak suspects:

Calculating Retained Sizes (How much memory is used, rooted at a particular object):

Track the pointers back to the GC (garbage collection) roots:

Thread and Stack information:

SQL-like language for querying the heap:

Shout-outs for this go to Andreas Buchen and the entire Memory Analyzer team. Thank-you for guys for such an awesome (and unbelievably useful) tool!

Note: I got these examples by running the memory analyzer on Eclipse, after analyzing a 670 Meg heap. It’s unbelievable, but the MAT heap was only 21 Megs. 21 Megs used to analyze over 1/2 a Gig. How cool is that?

Tags: galileo

As readers of my blog are no doubt aware, I have been counting down the Top 10 Galileo features that I’m most excited about. Galileo is the name of this years “Eclipse Release Train”, the simultaneous release of 33 Eclipse projects. Galileo will available for download on June 24th, but “Friends of Eclipse” get it sooner. Friends of Eclipse is a donation program setup by the Eclipse foundation.

Support the tools that support you. The best $35.00 you will ever spend.

Number 6 on my Top 10 list is the new Install Into Self option. While many people view the Eclipse SDK as an excellent Java development environment; it’s the extensible nature of this environment that makes it so powerful. Eclipse is assembled from 100′s of plug-ins, and while you may commonly use other peoples plug-ins, the true power of Eclipse comes when you start to develop your own. Before Galileo, the steps for building / testing / deploying / installing your own plug-in were quite cumbersome. This has all changed in Eclipse 3.5.

Using Eclipse 3.5 you can quickly develop your own plug-in (maybe it’s a new static code analysis view or an awesome new twitter client – All the cool kids are building twitter clients these day), and deploy it directly into your running instance. This makes development / testing / deploying much easier and enables all developers to “eat their own dog food”.

I consider this feature a “game changer” as it completely changes the way I work with Eclipse. Kudos for this feature go to Curtis Windatt with help from John Arthorne for p2 side of things. Thanks guys!

Tags: galileo, pde

This Thursday we had a great Galileo DemoCamp in Portland. Pictures from the event are on Gabe’s blog and Darin has posted a summary of all presentations. Thanks to the nice folks at Instantiations and the Eclipse Foundation Portland for putting this together!

You’ll find the slides of my presentation ‘RAP and the Eclipse Download Wizard’  below:

To learn more about creating apps for RCP and RAP from a single source, register for our free webinar on Eclipse Live:

Single Sourcing: Extend your RCP Application to the Web with RAP
July 9th, 2009 at 9:00 am PDT / 12:00 pm EDT / 4:00 pm GMT

Tags: democamp, galileo, rap

The next feature on the Top 10 Galileo Features (according to me) comes from the Eclipse Modeling Project. The Eclipse Modeling Project is arguably one of the most diverse, yet well focused, top level projects at Eclipse.

Number 7 on my list is the EMF UltraThin Diet. In January, the EMF team changed the way a number of fields and lists were generated. Since there are lots of overlap between classes in a hierarchy, and not all the allocated fields are ever used, the EMF UltraThin Diet enables a lazy memory allocation technique and combines many of the duplicated fields. Some estimates reduce the fields in an EObject from 120 Bytes to 12 Bytes!

While the details of this feature are interesting, the way in which one change can impact so many projects demonstrates the power of Eclipse. Many projects on the Galileo release train are built on-top of EMF, and this change will positively impact all downstream projects.  Beyond Eclipse, all users of EMF can apply this diet to their models too.

Ed Merks (with help from Dave Steinberg) get the kudos for this feature. You guys rock!!!

In addition to this change, there are number of exciting things happening in the modeling world. The XText project – A modeling project for creating domain specific languages, parsers, AST-Meta-models and an editor, from a simple EBNF grammar – is one of the most innovative projects in my mind. Also, the integration between Teneo and EclipseLink was one of the highlights of EclipseCon!

Thanks to the entire Eclipse Modeling Project!

Tags: galileo