Here’s the use case:  Say you have created a chat client built on the Eclipse RCP Platform.  Like any good software engineer, you’ve created extensive help content.  In addition to Instructions, you want to provide links that actually open the dialogs, or perform the actions. Active Help is the solution.

In this example, I’ve added a link that opens the “Add Contact” dialog, directly from the “Adding a Contact” Help page.

Doing this is extremely simple too. On the Java side, you simply need to implement the ILiveHelpAction.  Then, on the help side you simply add the following JavaScript to your help contents:

<a href='javascript:liveAction(
	"org.eclipsercp.hyperbola",
	"org.eclipsercp.hyperbola.ActiveHelpOpenDialogAction",
	"")'>Click here for a Message.</a>

The only thing to keep in mind is that the Action is not executed on the UI thread, so you may need to synchronize this yourself.

1. Andre Oosthuizen
2. Ed Burnette
3. Euxx
4. Frank Sauer
5. Gunnar Wagenknecht
6. Luis de la Rosa
7. Martin Perez
8. Vasanth Dharmaraj

They were the original 8 feeds on PlanetEclipse.  If you are interested in some of the first posts checkout this link.  Or, you can browse through time here.

For those of you that don’t know, planeteclipse is open to committers, contributors, or anybody with a passion for Eclipse.  If you have something to say, feel free to request that your feed be added (checkout the guidelines first).

Any ideas? Yes I’m talking about Eclipse, and the next release — Helios — has arrived. (For an an ultra fast download try our Amazon Cloudfront mirrors). While everyone seems to enjoy kicking off new software projects, specifying requirements and designing the perfect system, only to have it fizzle out — Eclipse is Different. Eclipse Delivers.

For the past 2 weeks I’ve been counting down the Top 10 Features of Helios that I’m most excited about:

10. Resource Improvements
9. Feature based configurations
8. Improvements to API Tools
7. Java IDE Improvements
6. Target Platform Improvements
5. p2 API and the b3 Aggregator
4. MarketPlace Client
3. EMF, Riena and RAP integration
2. Git Support at Eclipse

And my number 1 feature of the Helios release is: Xtext, Version 1.0.

For those of you who haven’t heard of Xtext, Xtext is a programming language framework. Xtext bridges the gap between grammars, models and programming language tool support. Using Xtext you can create a powerful environment for your own DSL (domain specific language) or full fledged general purpose programming language.

There are a number of important features that make this such a powerful toolkit, including generated editors that support code folding:

styled content providers:

quick fix support:

quick outline view, and more:

There is also a number of tools to help you create Xtext grammars such as Grammar Content Assist:

Xtext also supports project builders and can even derive a grammar from an Ecore model.

I’ve been following Xtext for close to 4 years now (from its origins at openArchitectureWare and through the Textual Model Framework proposal), and it’s great to see this excellent tool declare its 1.0 release. Xtext also received much deserved praise for its outstanding website, large collection of getting started material and they even won the Eclipse Community Award for most Innovative Eclipse Project at EclipseCon this year.

Great work Michael Clay, Sven Efftinge, Moritz Eysholdt, Dennis Huebner, Jan Koehnlein, Sebastian Zarnekow, Heiko Behrens, Peter Friese and Knut Wannheden.

Throughout this series I’ve tried to cover a variety of different Eclipse projects, but this list is far from complete. Please feel free to leave a comment with your favourite Eclipse Helios feature. Or better yet, why not write an article about it?

Over the life of Eclipse (Jeff McAffer tells me that he’s been working on Eclipse since 1999) a lot has changed. Eclipse started its life inside OTI/IBM. In November 2001 the Eclipse Consortium was announced and Eclipse was released as ‘Open Source’. For the next few years Eclipse grew, but was still mostly supported by a few large companies. New projects were proposed, new committers came on board, and Eclipse became the dominate player in the IDE space.  But as the popularity of Eclipse grew, so did its diversification. Then in April 2010, David Carver noticed that the number of active individual committers (those not associated with any particular company) was tied with IBM for the top spot.

What does all this mean and what does this have to do with the Eclipse Helios release? Well, as Eclipse continues to diversify, the Eclipse foundation will need a software revision control system that supports this diversification. The Eclipse Helios release marks the beginning of this transformation. Number 2 on my Top 10 List is: Git Support at Eclipse.

Three important components make up the Git support at Eclipse: JGit, EGit and the Git Infrastructure. JGit is a pure Java library implementation of Git version control system. JGit is licensed under the EDL has a number of users, including the Netbeans Git support.

EGit is the Eclipse tooling, and is build on JGit. There is currently support for a number of Git features:

History view:

Repository View:

Patch Support:

The JGit / EGit team has excellent documentation and there is some great information on Git in general.  Git is being worked on by Matthias Sohn, Shawn Pearce, Chris Aniszczyk, Mathias Kinzler, Stefan Lay, Robin Rosenberg and Christian Halstrick.  However, a really big thank-you goes out to the past (and present) committer reps for bringing Git to Eclipse.  The initial Git contribution provided a number of unique licensing challenges that required unanimous approval from the Eclipse board of directors.  Git at Eclipse would not have been possible without their hard work.

In addition to the tool support, Eclipse.org has rolled out Git infrastructure for the community to make use of. There are Git mirrors for Eclipse projects and even Git repositories that some projects have started to migrate too. The big thank-you goes out to Denis Roy and Wayne Beaton for this.  Git really is the future of Eclipse, and if all goes as planned, Git will be on my Top 10 List again next year.

Number 3 on my Top 10 list is EMF, Riena and RAP integration.

I’ll be the first person to admit that when I first heard about the Rich Ajax Platform (RAP) I didn’t get it. I assumed RAP was about re-recreating the Eclipse UI in a browser. I, like many others, quickly realized that this is not the point of RAP. RAP brings the Eclipse programming model – Jobs API, JFace content providers, SWT API, Stacks, Forms, Selection Providers, etc… to the browser. If you appreciate the Eclipse programming model, and more importantly, if you have invested in the Eclipse programming model, then RAP is your best friend.

Of course you *can* re-create the Eclipse UI in the browser:

but this likely is not what you want to do. Instead, you want to reuse your existing software and theme it for a rich web experience.

The concept of reusing your hard work across multiple mediums is known as Single Sourcing.  And it’s not just about the web; the new RAP protocol (not part of Helios) will open up a whole new world such as RAP on the IPad.

There are a number of notable new RAP feature in Helios including Opaque menus:

Drag and Drop:

New Themes:

Cheatsheet support:

Control Decorations:

and Graphics context support:

For these features, kudos goes out to Ralf Sternberg, Holger Staudacher, Tim Buschtoens, Ruediger Herrmann, Austin Riddle, Ivan Furnadjiev and Benjamin Muskalla.

While the new RAP features are incredible, RAP demonstrates the real power of Helios — cross product integration. Other Eclipse projects are starting to target RAP as runtime. In particular, Elias Volanakis has extended the Riena framework to make it work with RAP. You can now use the powerful Rigets on the web.

Finally, Kenn Hussey has extended the EMF Framework to target the Riach Ajax Platform as well as the RCP Platform.

Thanks everyone!

It was feedback like this that inspired Feature Number 4 on my Top 10 List: The Eclipse MarketPlace Client.

As we all know, Eclipse is much more than a Java IDE. In fact, Eclipse is an entire eco-system with thousands of plug-ins. Some of these plug-ins are packaged with the different Eclipse downloads. Other plug-ins are available as projects at eclipse.org. However, there are also thousands of plug-ins that are not hosted at Eclipse. Some of these are commercial tools developed for enterprise customers. Others (like one of my favourites — the vi plugin) have a small cost associated to help pay for the developers time. Finally, there is a large assortment of plug-ins available from a variety of other hosting sites. Finding and installing these components has always been a challenge, but with the Helios release this will all change.

The MarketPlace Client (MPC) makes it easy to browse and install 3rd party components. Available under Eclipse -> Help, this new feature should make it much easier to find the tools you need.

Also, unlike other ‘famous’ markets (or app stores), the Eclipse MarketPlace Client is plug-able and open, meaning vendors are free to create custom market places for their particular needs. Helios currently ships with 2 marketplaces, one from Eclipse.org, and the Yoxos Market hosted by EclipseSource. The two markets are slightly different in that the Eclipse MarketPlace lists plug-ins for a variety Eclipse versions, while the Yoxos MarketPlace is a curated repository of Helios related content.

It was the great work from David Green and Steffen Pingel that brought us this feature. Nathan Gervais from the Eclipse Foundation did the server side work, while Ian Skerrett was the point person behind all of this.

In addition to the MarketPlace, the Eclipse Foundation, with the help of Google, have launched the Eclipse Labs.

Eclipse Labs is a community of open source projects that build technology based on the Eclipse platform. It provides the infrastructure services typically required by open source projects, such as code repositories, bug tracking, project web sites/wiki. Eclipse Labs is hosted by Google Code Project Hosting, so it will be very familiar to developers already using Google Code Project Hosting.

Combing the market place with Eclipse Labs will make it much easier for developers to create, publish and distribute their products to the community.

On Monday I discussed the importance of API when it comes to Eclipse projects. The p2 team has been working on the API for almost 3 years now and when Helios is released the p2 API will be official. What does this mean? It means you can build provisioning solutions around p2 without worry that the entire system will change from under you. In fact, I’ve been on both sides of the p2 fence: helping to define the API and then building the new Yoxos Launcher and Yoxos Enterprise solutions, using this technology.  If you are building a system that needs SelfUpdate, Install, Uninstall and RollBack, and you have anything more complicated than a few static dependencies, you should really consider p2.

Here are some of the API highlights:

1. Support for multiple agents: This means you can manage multiple applications using a single controller. Once you create (or acquire) the agent, you can acquire agent services for: computing provisioning plans, working with metadata, working with artifacts, performing installs, etc… We make heavy use of this in Yoxos since our systems can both update themselves and manage your Eclipse installs.

2. A new approach to Queries: Querying metadata is an essential part of any provisioning system and p2 now supports both a p2 Query Language and a simple QueryUtil class to create the most common queries.

3. Java 5 generics: No we did not just leave all the Java 1.4 people behind and finally decide to move to Java 5; but rather, p2 now uses generics and down-compiles to Java 1.4 for backwards compatibility. This is a huge step forward for all the Java 5+ developers out there.

4. The operations API: The saying “Make easy things easy and hard things possible” has been on our mind as we designed the p2 API. While p2 has a very powerful planner (award wining planner I should add), the idea of crafting provisioning plans and executing these plans on an engine in order to affect a profile, is quite frankly — complicated! Using the operations API you can easily invoke common “operations” like update this item, or install this other thing. For an idea of what’s involved, please see our help documentation.

5. Real API: You will notice that we dropped provisional from many of our package names. Feel free to browse the p2 API Java docs.

There are also a number of improvements to the API to make things more consistent.

Thanks goes out to the entire p2 team for all the hard work (and heated discussions ). In particular, John Arthorne, DJ Houghton, Thomas Hallgren, Susan McCourt, Daniel Le Berre, Simon Kaegi, Andrew Niefer, Henrik Lindberg, Matthew Piggott, Tom Watson and Pascal Rapicault.

In addition to the API, Steffen Pingel and Susan McCourt have worked on a new Discovery UI which can be used to provide a branded presentation of a p2 repository. Tools like Mylyn use this UI to make it easy for users to install Mylyn Connectors.

Finally, there are other projects around Eclipse.org that make working with p2 a little easier.  PDE/Build, b3 and the newly proposed Tycho project make it possible to build p2 repositories.  However, one project is the real workhorse behind the Helios release — the buckminster / b3 aggregator.  The aggregator combines repositories from various sources into a new aggregated p2 repository. The aggregator has both a UI component and can be run headless (i.e., you can aggregate p2 repositories as part of your build process). Also, you can use the aggregator to get a detailed view of what’s in a p2 repository.  For more information on this impressive tool, checkout their wiki page.

In addition to creating aggregated p2 repositories, the b3 aggregator can produce maven repositories.

Kudos for this work goes out to Thomas Hallgren, Henrik Lindberg, Filip Hrbek and Karel Brezina.

Regarding source code management, there’s a endless debate over which tools, technologies and techniques we should use. In fact, most University curriculum’s spend a great deal of time on how to best architect, design, document, write and manage source code.

However, when it comes to the management of your 3rd party libraries — the code you need but you don’t write — this is very much an ad hoc process. Finding dependencies, including them on your build path, finding the corresponding source, determining (and locating) which version you need, etc… is mostly a manual process:

1. Figure out what jar you need (Apache commons collections for example)
2. Use google to search for the jar
3. Add the jar to your path
4. Run
5. Look at the errors
   • Did you have the right version
   • Did you miss any dependencies
6. Figure out what else you need to find
7. GOTO 2

Lucky for us as Eclipse developers, PDE’s Target Platform and Target Definitions make this process effortless. You can define and share you dependencies with your team. If you are missing a dependency, it can be automatically provisioned and placed on your build-path.

Eclipse 3.6 is hitting the shelves (or at least the download mirrors) in 1 week, and to celebrate this release I’ve been counting down the Top 10 features I’m most excited about. Number 6 on my list is the Improvements to Target Platform Management.

In Eclipse 3.6 you will be able to search repositories and quickly add components from these repositories to your target platform (Ctrl+Shift+Alt+A).

In addition to this, a new quickfix allows you to search repositories for a missing import package and have a bundle supplying the package added to your target.

Finally, one of the biggest headaches for release engineers is collecting all these bundles that constitute your target. There is now a new export wizard that will export all the bundles in your target to a single directory. The tool will also generate a p2 repository. This repository can then be used in your build as a repoBaseLocation.

A big thanks goes out to Chris Aniszczyk and his army of Minions for this work .

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.