Galileo is here!!

If you are reading this and you probably know Eclipse Galileo is out today!!. Have you downloaded it already? No? what are you waiting for? :-)

Configuring API Tooling for existing projects

API Tooling is not a new feature. It came out of incubation in 3.4 and has been explained nicely at developerworks and eclipse wiki. What I would cover below is how to do it for existing projects and the strategy to continue with it.

1. Setting up API Tooling
Note: API Tooling works only for plug-in projects. It can not be used for Java, Feature and Update site projects API Tooling for a project is setup by attaching an API Nature to the project. When completed you will be prompted to make a baseline.
2. Baselining
A baseline is a snapshot (set) of plug-ins. The AP Tooling expects not just the plug-ins you exported from your workspace, but also the dependent plug-ins. If the complete set is not available, the Compare with baseline will not work. If your plug-ins makes a product, then export the product configuration and point to it as baseline. If its a set of features then just exporting them will not be enough. The dependent plug-ins are required too. You pull them all by modifying your ant build script. I don't know any shortcut/simple way of achieving this.
3. Comparing with baselines
API Tooling is a new view available with3.5. It can be quick accessed through context menu (Compare with > API Baseline...) on a project, a folder, a package or any java resource in package explorer. Compare Baseline compares the selected resource with the selected baseline. Any changes are reported in the API. Note that you can compare two baseline with each other here. Its the code against the selected baseline.
4. Going ahead
Having a baseline on each minor version will be a overkill. I would have one for each major release and one for each milestone during the development cycle. API Tooling can also be integrated in the PDE Build. Look for Eclipse help contents PDE Guide > Reference > API Tools Ant Tasks. For a quick list type apitooling in build.xml and press Ctrl + Space (content assist). API Tooling view allows exporting the results as XML or HTML. Same can be automated using ant tasks.

When a n00b met Galileo

First time I used Eclipse it was Europa. Completely missed Ganymede. And it was only early this year I saw Galileo taking shape. So this review comes from the perspective of a relatively novice plug-in developer.

Things I liked

1. API Tooling
This one is really impressing. I know its not new and had been around @since 3.4. But the new baseline compare feature is really lovely. I remember spending hours, sifting through the CVS history, to figure out who changed that function signature and when.
With the new API Tooling view, we can now compare the code with any baseline and figure out what all got changed. Chris explains it in detail here.
2. Hyperlinking
Wow! Just Ctrl + Click on the variable, function, whatever....it takes you to the declaration. F3 is cool. Does the same trick. But when I am browsing the code, following the call stack, Ctrl + Click is my scout. And where it betters the F3 is if its a method from interface, it lets you choose where you wish to go - declaration or the implementation. Mostly its the later one we want, isn't it?


Hyperlinking

3. Export wizard enhancements
The new "Use class file compiled in the workspace" option is such a time saver. I almost always have the "Build Automatically" checked. Glad that I don't have to wait for all the features to compile all over again when I export then. It just picks the class files from the bin directly. Also, its not very easy to export the plug-ins along with source bundles.
4. P2
It took a while to figure out just that P2 means Platform Provisioning (correct me if am still wrong). This is perhaps the next big thing in Eclipse, but frankly I have no clue how it works and will take some time to catch up. Then what  I like about it? Installation history and the fact that I can now actually 'revert' back the feature I installed for testing. Don't have to make a copy of eclipse to try it over it. If I don't like I can get rid of it.

Things I wish for

I feel the API tooling is yet to grow to its full potential. I'll like to see support for tentative API and better reports. The PDE UI need lot of working. Like Cheat Sheet editor is a PITA when you have to bulk update. P2 may have liberated the release engineers but I strongly feel it needs lot of help material to reduce the entry barrier for n00bs like me.

The wish-lists are always endless. With Galileo edition, Eclipse has come a really long way. And with E4 the vision reaches out farther than I can see. Glad to be part of Eclipse community.

[New in Eclipse 3.5] Target Definition Editor make over

The new Target Platform story has resulted in a few changes to the Target Definition Editor.

The Environment page remains unchanged. The Overview page has been renamed to Definition page. The page is less confusing now. Earlier it had the workspace target topped with additional directories. But now its just a set of locations which can be any directory, eclipse (or eclipse based product) installation, features or can even be an update site.

Target Definition Editor - Definition Page

The Content page too as gone simpler. It not only shows the constituent plug-ins for the selected locations but also helps in choosing the individual plug-ins out of each location. The plug-ins can be filtered and also be grouped by their location or the file path. As before, the Add Required button adds the required plug-ins for the selected ones. And the good thing is that it searches for the required plug-ins in all the available locations.

Target Definition Editor - Content Page

[New in Eclipse 3.5] Plug-ins Import Wizard refurbished

The Import Plug-ins and Fragments wizard has gone under knife in Galileo release. It has been made simpler and consistent with the new target platform story.

Before & After

as seen in Eclipse 3.4.2                           new look in Eclipse 3.5

The import has been made simpler by providing three simple options to import from.

1. Active Target Platform
The Target Platform Preference page now allows you to maintain various target definitions.  However, only one can be active at a time (of course). It is this target that the workspace is built against. So this is option to be chosen if a plug-in has to be imported from the current target platform.
2. Registered Target Definitions
By 'Registered' Target Definitions I mean the local target definitions (using Target Platform Preference page) or any target definition file that exists in the open projects. Any external target definition file (outside workspace) that was opened in current session is also remembered.  Simply speaking, any target definition that appears on the Target Platform Preference page. Using this option, a plug-in from any of the these target can be selected for import.
3. Directory
This one is easy. Choose any plug-from the specified directory location. The option is smart enough to locate and pick  from the "plugins" directory also under the location mentioned.

The Features Import wizard remains the same. No changes to it.