Okay, then I cannot tell you any news, but the participating projects at Eclipse shipped another coordinated Simultaneous Release in time! This Indigo SR2 release contains many improvements and bug fixes, e.g. an update of the underlying platform to 3.7.2. It’s worth an update!

The packages for Indigo SR2 RC2 (the second release candidate for the second service release of the Indigo release, based on Eclipse Platform 3.7.2) and the packages for this year’s Simultaneous Release Juno M5 (the 5th milestone based on Eclipse Platform 4.2) are available:

http://www.eclipse.org/downloads/index-developer.php

Please test and report any issues in Bugzilla. Especially the Eclipse 4.x team needs your help! The sooner bugs are found, the sooner they can be fixed!

One of the changes is the addition of Eclipse Code Recommenders to the Eclipse for RCP and RAP Developers package.

For those who couldn’t attend you can find the slides below, for those who were in the room, here is the URL to our distributed demo search application that is still running on the cloud:

cloudle.eclipse.org/search – server has been shut down

We asked the audience at the very beginning of the talk to give us a URL of a website. Then we used g-Eclipse with a small JMX-management extension that we implemented for this talk in order to configure the SMILA framework running on several cloud nodes. (If you don’t know what SMILA is: It is a framework for building search solutions, in our case it was the glue between our exemplary back-end Apache Solr and a small RAP-based search front-end.) The next step was to start the web crawler on this remote machine with g-Eclipse to give it some time to download the web pages below the given URL and to build up an index.

At that point in time I saw some network timeouts. Not a good sign but maybe only a temporary problem that goes away after some minutes, some minutes that we were using to explain what we did. See the slides yourself:

Our exemplary (and simplified) architecture has one front-end node that is running our little RAP search-UI, and several back-end nodes, each of them with a search index of its own and crawling a different set of URLs. At the end of the talk it was planned to make the remote machines known to each other and that means in this case that the front-end needs the addresses of the back-end nodes. Once again, we used g-Eclipse to add the other back-end nodes to its configuration.

Just for the records… it worked well when we tested it before the talk, and it worked immediately after it. Unfortunately we had some kind of weird network problems in our session.

In the meantime, I’d like to highlight some additions that I recently did as a package maintainer of the RCP package. (If you don’t know what a package maintainer is you should consider joining my talk on Monday about ‘Building EPP packages‘.)

• git is becoming more and more popular at Eclipse and EGit is always one of the first plug-ins that I am installing whenever I unpack a new Eclipse milestone on my computer. The logical step: Include EGit in my RCP package because I think that I am not the only one who needs this tool.
• Another addition that I recently made is the RAP tooling. My daily work has changed and in the last months I am doing more RAP development than RCP development. I am not entirely sure if one needs both in one package, maybe RAP needs to go into its own package, but so far I think both technologies  complement each other. I am happy to get feedback – see bug 230357.
• Last but not least: The Marketplace Client (MPC) is included to allow early feedback – the developers of this nice tool need your feedback to bring it into the best possible shape for Helios!

Now let’s wait until the packages are available… and I need to go back preparing my EclipseCon slides.

Or, if you don’t want to download the full packages, you can start an upgrade – that’s what I did just a few minutes ago. I started with an older working copy of Eclipse (probably something from Galileo SR1) and started the upgrade process (‘Help’ > ‘Check for Update’).

It takes a while until p2 fetches all the required metadata from several repositories. The list includes the EPP package repository with the package definitions, the main Galileo repository and the Eclipse Platform repository. A few Okay-clicks later, p2 started to download the new content and asked me some more minutes later to restart Eclipse. Et voilà – after that restart I had a brand-new Eclipse with the latest version without downloading a new package.

You can go ahead and download one of the Helios EPP packages from this URL

http://eclipse.org/downloads/packages/release/helios/m4

or you can update with the Release Train repository and the features from all participating projects from this URL

http://download.eclipse.org/releases/helios/

Everything is based on Eclipse 3.6M4.

Thanks again to everybody who helped to make this happen!

I am proud that I am able to announce the availability of the corresponding Helios EPP M2 packages. You can download them from the usual EPP nightly build page www.eclipse.org/epp/download.php.

It’s the first time ever that the EPP packages are available so soon in the yearly release cycle and I think it is a good opportunity to get a lot of early feedback. The Eclipse Platform team did this all the time, but hopefully this will help other projects to get more testing by the community.

Thanks to all that helped to make this happen!

First of all, there is bug 281501 “64 bit Cocoa EPP packages should be available” which is currently the most wanted bug at Eclipse. I never thought that I would ever be the one who owns the bug with the highest number of votes, but finally it is solved and 64-bit Cocoa packages will be available with Galileo SR1. If you have a Mac and if you are able to run these packages, download one of the 20090920-1025 builds, test it and report on the above bug. I would be thankful for additional testing because I am lacking the possibility to test on this platform.

Another great achievement is the ability to upgrade the packages with the help of p2. This morning I tested to upgrade several Galileo packages to the new service release and it worked very well! Look at the About Dialog of the RCP package before the upgrade  – I started with a pristine download from eclipse.org/downloads:

Then I had to modify the URLs of the p2 repositories in Window > Preferences > Install/Update > Available Software Sites – see the screenshot below. Note that this step is only required until the final bits are released, because they are only available from a temporary location at the moment. After the release nobody has to change anything here, especially the EPP repository URL is only temporary for build 241.

The last step is the update itself (Help > Check for Updates). This takes some time, but at the end I could restart my Eclipse RCP package and it started with the new Galileo SR1 version:

I am happy to see this working!

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!

Why am I writing this? The main reason is that we – myself and all the other package maintainers – like to get feedback about the packages. This year, we provide even more packages! There will be a new PHP package (the name is self explanatory) and the Pulsar package which contains the bits from the Pulsar Working Group.

Back to the main topic: Feedback. If you want to send us bug reports about the packages, you can do so by pressing the “more…” link on one of the download pages:

This will bring you to a page where you can find in-depth information about every package. On the right-hand side, you will find a section with download links, MD5 and SHA1 checksums, but also relevant Bugzilla queries and a direct link that allows you to send bug reports about a particular package.

But before opening a new bug, please read through the list of open bugs to avoid duplicates and consider filing the bug against a particular project if its related to a project and not to the package itself.

…and the logo that appears on every eclipse.org web page reminds me again: Galileo arrives in just a few weeks!