As Eclipse committers, we spend lots of time emphasizing that Eclipse is not just an Integrated Development Environment. Eclipse is a framework, a tooling platform, a collection of run-time technologies, an eco-system, etc… However, at the end of the day, an IDE is the primary use of Eclipse for many people.

As we approach the next major release of the Eclipse platform — Helios — I’ve been counting down the features I’m most excited about. Number 7 on my list are the Enhancements to Eclipse as an IDE. These are features that will make your life easier as a developer (many of these features are Java specific, but not all).

The Java Development Team has released a number of new code formatter options:

While these are cool, the most exciting one (in my opinion) is the ability to disable formatting for certain code blocks

There are even a number of improvements to comment formatting.

As well as code formatting, the JDT team has introduced some new capabilities including: a breakpoint details pane

object instance counts

and static analysis improvements:

Huge kudos go the very active JDT team, including: Jayaprakash Arthanareeswaran, Deepak Azad, Frederic Fusier, Walter Harley, Ayushman Jain, Satyam Kandula, Markus Keller, Dani Megert, Kim Moir, Michael Rennie, Srikanth Sankaran, Olivier Thomann, Raksha Vasisht, Curtis Windatt and Darin Wright.  Over the next year the JDT team will be focusing on Java 7 support. If you are interested in helping with this effort, why not get involved?

In addition to Java specific enhancements, the Eclipse Platform team has been working on general IDE improvements.  One feature that really caught my eye was improved patch support.  Last year the Platform team improved the Java Compare Editor. However, these changes did not extend to the apply patch wizard.  As of Eclipse 3.6 this doesn’t matter because you can now use the synchronize perspective to apply patches:

This makes patch review a much easier process, especially since you can now apply a patch directly from a URL:

The Platform team (especially Tomasz Zarna and Szymon Brandys) deserve the credit for this work.  Thanks everyone for making my life as a Java Developer easier.

Tags: helios

I’ve been thinking a lot lately about what defines an Eclipse project? Not in the literal sense (a project hosted at eclipse.org that follows the EDP), but rather, what technical qualities do all Eclipse projects share.

Years ago the answer was simple, extensible IDEs. More recently Eclipse was defined as a tooling platform (for everything and nothing in particular), but when you start to look at where Eclipse projects are being used (Eclipse RT and modelling projects in particular), you realize that ‘a tooling platform’ doesn’t begin cover the spectrum.

Even eclipse.org has got out of the business of defining Eclipse. And while defining ‘Eclipse’ might not even be possible, there are a few technical qualities that all Eclipse projects share:

1. OSGi Based (most projects produce OSGi bundles)
2. A strong commitment to API
3. Meaningful versions

It’s the last two points that I want to focus on here.

Most Eclipse projects defined their versions based on API. We don’t use version sequences like 3.0, 3.1, 95, 2000, XP, 7. Instead, Eclipse projects define their versions such that a change in a version number indicates API compatibility (or incompatibility). There was an excellent tutorial at EclipseCon on this topic, and I believe that the connection between API and versioning is so important that it should be part of the undergraduate curriculum for software engineering.   Like many software engineering activities, manging the relationship between your API and version number is challenging, but it can be aided through tool support. Lucky for us there is an entire Eclipse component dedicated to API tooling.

As we approach the Helios release, I’ve been counting down the Top 10 Features I’m most excited about. Number 8 on my list is Improved API tooling support.

API tooling has been included in Eclipse for a number of years now. When you enable API tooling as consumer of API, you can identify when you are using methods you shouldn’t be:

Producers of APIs can use the tooling to help identify when they have ‘broken’ API:

While these features have been around for a number of years now, there are some noteworthy additions to API tooling. There is now a launch configuration which can be used to track API usage and generate HTML reports. This allows producers (and consumers) to see who is accessing non-API packages / classes / methods:

While this is valuable information, most most exciting advancements of API tooling is the new Migration Report. Using the migration reports we can determine if our bundle(s) can be (easily) migrated to a new version. For example, if the API producer decided to change the signature of their apiMethod to include a new parameter (and they properly released version 2.0 of their bundle), we could run the migration report and as a consumer.  Doing so would uncover any migration issues. In particular, on Line 10 in the doSomething method, we invoke a method that no longer exists.

More information on the migration tasks can be found on the Eclipse help system.  Thanks to Chris Aniszczyk, Michael Rennie, Darin Wright and Olivier Thomann for this work.

Note:  If I missed someone in the kudos, please let me know. I do my best to track down who worked on each feature .

Tags: helios

Yesterday I asked you to think about high-quality software that has been consistently delivered on-time for eight straight years. To make this quiz more challenging, this software should be installed on millions of users’ desktops.

As we approach the next major release of Eclipse — dubbed Helios — I’m counting down the top 10 features I’m most excited about. Yesterday’s feature was the improvements to Resources. Number 9 on my list comes to us courtesy of the Plug-in Development Team: Feature based targets and launch configurations.

I’ve read many articles over the years that compare IDEs. These articles often critique the support for particular programming languages. For example, some IDEs support Closure, or Haskel better than others — and if you use these languages then you should use the tool that best supports your workflow. For me, one of the most important IDE features is OSGi tooling. I spend my days writing bundles, crafting configurations, wiring together services and deploying OSGi based applications. Nothing compares to the OSGi tooling provided by Eclipse. The OSGi tooling is part of the Plug-in Development Environment. The reason it’s not called the OSGi Development Environment is strictly historical (these guys were doing OSGi tooling before it was cool).

Feature based targets and launch configurations make configuring your OSGi applications much more manageable. Features provide developers a way to ‘group’ bundles together and talk about things at a higher level. Instead of talking about the p2 engine, and p2 director, and p2 core, and all other bundles that ‘make-up’ p2, we can group these together into a feature — the p2 feature. For those of you wish you craft OSGi applications that include p2, you can simply use the p2 feature (instead of worrying about the particular bundles that constitute this feature). The real thank-you for this feature goes out to Ankur Sharma and Curtis Windatt.

This will become more and more important as Eclipse continues to grow in the Run-time space.

Tags: helios

Tags: iAd, IPad, iphone, protocol, rap

Pop quiz: Can you name any ‘high quality‘ software that has been consistently delivered on-time, for 8 years in a row?

Yes folks it’s that time of year again! It’s time for the Eclipse Release Train to start revving up its engine for another high quality release. Unlike other software — which gets delayed, bumped or put-on-the-back-burner — Eclipse just simply, delivers.

The official Eclipse release — named Helios — is not arriving until June 23rd, but in keeping with tradition, I thought I would help count down the next 10 business days with the Top 10 Helios features I’m most excited about.

As many of you know, Eclipse is no longer Just a Java IDE. Eclipse is a tooling platform, Eclipse is runtime stack, Eclipse is set of world class IDEs, Eclipse is an eco-system, Eclipse is like family. Before I start to count down my favourite features, I should state that I only use a small subset of Eclipse. There are some really exciting things happening in the C/C++ development tools. The SWT team has added some fantastic new MacOS and Windows Vista support.

The Birt and Web tools team continually pump out great code. While all these projects are doing cool things, sadly, I don’t get to use them on a day-to-day basis.  Because of this I can’t talk about them here. As I’ve said in the past, this really is My Top 10 List. So please — if you disagree with me — write your own Helios Review (you might even win a prize).

Number 10 on my list is Resource Improvements. This includes everything from virtual folders to the file permission management.

As well, a number of enhancements have been added to the Open Resource dialog.

Thanks goes out to the Resource Team, and in particular Serge Beauchamp, for this.

In addition to the improvements to resources, one of the oldest feature requests related to files has finally been fixed: Bug 4922 (yes, a 4 digit bug number). Eclipse now has the ability to open a file from the command line (and have it open in an existing running instance of Eclipse). While this may seem like a trivial enhancement request that all IDEs should support, the API behind this feature is what makes it so interesting. As RCP developers, you can make use of this API to load data files into other running processes. As Eclipse programmers you can double click Java files and have them open in Eclipse.  And like everything in Eclipse, this works across platforms.  If you’re interested in the technical details, checkout Andrew’s Blog. Huge kudos go out to Andrew Niefer, Kevin Barnes, and Oleg Besedin.

Tags: helios

It’s been overcast and raining here in Victoria B.C. (Canada) over the past 2 weeks. It’s a long way from the dog days of summer, but a good time to focus on docs.  In fact, the Eclipse team has been focusing on documentation during this final release candidate.  In particular, the p2 team is putting some docs together on our new API (Yes, p2 has “real” API now).

Last year Andrew Niefer gave me a few tips on self-hosting the doc / help contents and I thought I would share these.

The help contents are written in HTML files and live in OSGi bundles (like everything else).  For example, the platform doc lives in org.eclipse.platform.doc.isv. Once you have your bundle loaded (from CVS, git, wherever) you can edit the contents like any HTML other document.  When you want to see how the contents will appear to the user, simple launch the org.eclipse.help.base.infocenterApplication, and specify a port as a VM argument (-Dserver_port=4419 for example).

Once running, you can now browse the help contents using your favorite browser (and even change the contents on the fly).

Of course if we get our butts in gear and follow David Green’s advice, we won’t need to edit our docs this way.

Tags: documentation, helios, p2

Based on your feedback on my last blog posts, I’ve implemented a first prototype of the RAP protocol. Here’s an update on the current state. Several functions are now implemented e.g. server side message creation, client side message processing, client side message creation and server side message processing. The cool thing about all this stuff is that it works already with the RAP lifecycle. To demonstrate the use of the protocol, I migrated the Shell widget. You can see the results in the screenshots below.

The first screenshot shows the protocol based shell. You can see that FireBug is open and is showing the JSON response from the server. The second screenshot shows a JSON request that was sent from the client to the server. The current protocol implementation is a hybrid, which means that it uses JavaScript and protocol messages. With this hybrid it’s possible to run the RAP workbench on top of the protocol based shell.

If you want to test this shell yourself you can use the RAP protocol git mirror which can be found on github. At the github wiki you can see what bundles you’ll need to run the protocol based shell. To start the protocol shell just run the launch configuration within the org.eclipse.rap.rwt.protocol.playground bundle. The code for the protocol is in a very early state, so please be warned that there could still be drastic changes in the code base.

The next step in the development of the protocol will be to test it on a different client technology. For this purpose a demo for the iPad would be the perfect candidate. AdLib is a JavaScript library which brings native like widgets to the iPad’s mobile safari browser. And, I think it will be possible to use this library with RAP and the protocol. I will keep you posted on the progress of the iPad demo. Looking forward to your feedback.

Tags: eclipseRT, protocol, rap

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