Either You Succeed or Explain

Ten Tips for Installing Plugins in Eclipse Galileo

Eclipse Galileo (3.5) has a shiny new plugin installation dialog box. In fact, the whole process went through a complete re-factoring. This has become a tradition in Eclipse: 3.3 and 3.4 each had a completely different plugin installation routines. 

While the process itself is simpler in Galileo, there are still some issues you should be aware of. Here are some pitfalls to avoid and tips to make the process smoother. Most of these tips are around the Install dialog box found under Help → Install New Software. 

1. Do not "contact all update sites" unless you have to

There's a small check box in the Install dialog box labeled "Contact all update sites during install to find required software". On the face of it, it sounds like a very good idea: if you install a plugin and your platform does not have all required plugins, it will simply find them and install automatically. 

In reality this has some unwanted side-effects: first, the process may be slower because Eclipse may contact more update sites then you intended. Some sites may not be that fast for you (especially if you are not in North America). This is not the worse part, though. In this process, Eclipse may find other tidbits which are not entirely related (see the next point).

Clearly, this process needs perfecting. My suggestion: uncheck this box. If some dependencies are missing you will be notified at the next step and you will not be able to proceed without it. In that case, turn it on and... (read the next section)

2. Carefully review what you are about to install

After you select the plugins to install and click next, Eclipse performs several checks. The next dialog box is very important. Do not dismiss it automatically by clicking next. Read the messages and make sure you understand what you are signing. 

In some cases, there may be added plugins which are unrelated to what you are about to install and you may choose to remove those (which may not always work).

3. Be wary of "grouping items by category"

The next check box to tackle is "Group items by category". This seemingly harmless button does more than you think. True, it will group the items you see by categories, which is something you want. However, if the items on the site are not categorized they will not appear at all, thus, you will not be able to install it.

Newer sites are supposed to be categorized (supposed being the key word here). Older sites may be uncategorized. This is very confusing for novice users, so be careful. It is also an important note to people building update sites: make sure you categorize your plugins, even if you have just one.

4. A lot is going on in the background

The update sites are contacted in the background. You can see the progress in the lower right corner of your screen. Fortunately, in Galileo you can actually cancel this process (which used to hang in Ganymede). The background fetch may continue after you close the Install dialog box, even if you didn't install a thing. 

5. Installing EPP packages

This tip should be in a completely separate article because it is very important and many people are not familiar with it. EPP stands for Eclipse Packaging Project. It is the project responsible for creating the Eclipse download packages. 

When you first download Eclipse, you need to select your package: "Eclipse IDE for Java Developers", "Eclipse IDE for PHP Developers", etc. These packages are created as part of the EPP.

What if you want an Eclipse IDE for Java & PHP Developers? Very simple. Start by downloading one of the packages and add the other package from the update site. You can download the Java package first and once it is running, do the following:

1. Go to Help → Install new software.
2. From the sites drop-down, select the site titled "EPP Package Repository"
3. Select the "EPP PHP Feature" and follow the rest of the installation process.

This is a very easy way of getting the entire package into your IDE. The same technique can be used to install a 64-bit Mac OS X package, although such option is not available on the main downloads page. See more details here.

6. Drag and drop archives

If you have an archive which contains an update site, you may simply drop it inside the Install dialog box to add it to your site list. This works on Windows and does not work on Mac OS X. 

7. All sites are kept

Keep in mind, that Eclipse does not "forget" update sites, unless you specifically ask. For example, if you entered a wrong URL or a temporary archive, it will always be there. To remove it, you must go to the "Available Software Sites" preferences page and specifically remove it. You can access this page directly from the Install dialog box by clicking the link "Available Software Sites". 

The preferences page will show enabled and disabled sites. You can disable a site without deleting it. Disabled sites will not be searched when looking for updates or missing plugins. However, you can still find them by typing part of their name in the address box of the Install dialog box. There's no need to enable the sites first: once you find the site and select it, it will be enabled automatically. 

8. Restart after installing a plugin

Eclipse is based on a powerful framework called OSGi which enables reloading dependencies and plugins. Yet, from my experience, there's a chance it won't work. So, although it is possible to continue without restarting, please don't.

9. Uninstalling

Uninstalling plugins can be done from About Eclipse → Installation Details → Installed Software. Just pick a feature and click Uninstall. You can get to the same dialog box from the Install dialog box by clicking on "What is already installed?".

Note that Eclipse may still contact update sites and install updates while uninstalling plugins. This is a bug which will hopefully be fixed in future versions. To avoid that, you may disable the update sites in the "Available Software Sites" preferences page. 

10. There are other options

The sheer complexity of the plugin installation process created a need and it was clear that this need could be filled by 3rd party tools. Personally, I use Pulse, which has a free edition, but there are several other good and free options out there. 

These tools will replace the standard plugin installation procedure with a more simplified one. They often offer a catalog of plugins which you can just select and install with a simple drag and drop operation and faster servers. It's the end of the infamous "plugin hunt". 

Specifically in Pulse, you can also build and maintain your own configuration which you can install and reinstall with one click. You can also share it with your team. I really recommend looking into these options for novice users and power users alike. 

Eclipse Galileo for Mac: Cocoa or Carbon?

Eclipse Galileo (3.5) is released today. Mac users downloading the new release will notice that, unlike previous releases, they have some interesting choices to make. They need to choose between "Mac OS X (Carbon)" and "Mac OS X (Cocoa)". There's also a third choice, which is currently not mainstream, the "Mac OS X (Cocoa) 64 bit". So, which version is right for you?

Answer: Download the 32-bit Cocoa implementation. Here's why.

Here's a brief and (over?) simplified background:

• The Mac OS X provides a native API called Cocoa. It replaced the earlier implementation called Carbon. Carbon is being phased out and one of its' main limitations is that it is only 32 bit. 
• Java 6 for Mac OS X, introduced last year, is 64 bit only. This is, BTW, a real annoyance, since you must have a 64 bit capable CPU to run it, i.e. an Intel Core 2 Duo. 
• SWT is the GUI framework behind Eclipse. It is written in Java, but it is different from other Java GUI frameworks (like Swing or AWT) in the fact that it actually wraps the OS native UI widgets, providing native look and feel in each OS. This means SWT has a different implementation for each OS. 
• The current SWT implementation for OS X is based on Carbon.  Thus, it cannot use Java 6 on OS X (at least not the Apple JDK).

There has been an effort to release a Cocoa version of SWT for Mac in the Galileo time frame. It was clear that the Carbon SWT is a dead end. This release is finally ready.

Now back to the main question: which one should you use?

Let's first clear the 64 bit issue. You can use the 64 bit Cocoa implementation. It requires Java 6, which is available on Leopard (OS X 10.5.x) only and requires an Intel Core 2 Duo processor (not Core Duo). If you bought a new Mac in the last 2 years, you are likely there. You can check your processor by selecting "About this Mac" from the Apple menu. 

You will need to use it if you have an Eclipse plugin which requires Java 6 to run or if you are developing such a plugin or an RCP application (which means you are limiting your target audience). I am not familiar with any popular Eclipse plugin which specifically requires Java 6. You may also use it if you intend to break the 32-bit memory addressing limit with your Eclipse IDE (which is almost 4 GB). 

In all other cases, there's no reason to use Java 6. From my initial tests it does not feel faster. Plus, it has limitations like the inability to run the SWT_AWT bridge (some plugins may use it). It uses more memory which is obvious since addresses take more space. You can, BTW, develop Java 6 applications with Eclipse running on Java 5. 

My current recommendation is: don't bother. Use the plain 32-bit version. If you still want to test it yourself, the 64-bit version can be downloaded here.

Back to the main question: Cocoa or Carbon?   First of all, they look the exactly same. Although Carbon is more mature and thoroughly tested, the new Cocoa implementation offers advantages and improvements. There are some obvious features like Sheet support, which is implemented in a few places like the "save as" dialog. However, it's the little things that make the big difference.

Here's just a few examples:

• Improved behavior of the Zoom button (the green button in the title), finally.
• Much better Spaces support. 
• Plays nice with the Dock when it is positioned on the left of the screen.

These are all minor issues, but they make your life much better. I'm sure you will appreciate the Cocoa Eclipse. I do. 

Meet me at the Eclipse Galileo Tel Aviv Demo Camp!

It's finally here!  The first Eclipse DemoCamp in Tel Aviv will take place this Thursday, thanks to my good friends at Zend Technologies. 

We have a packed agenda and over 40 people signed up for the DemoCamp. We will do our best to make this meeting informative and set up the foundations for a true Eclipse community in Israel. We also have some fun surprises, so... if you are an Eclipse fan in Israel, you don't want to miss this. 

See you there.

Using Java Assertions? Use an Assertion-failed Breakpoint!

I'm a big fan of assertions. I use them very often in my code as safeguards. I was very pleased when true, native assertions were introduced to Java: they allow adding more tests while keeping the code running faster when disabled. 

If you like assertions, you will appreciate the following tip. A failed assertion will throw a java.lang.AssertionError runtime exception. Logging the assertion failures is up to the application code. If your code does not report this error properly, you may completely miss the assertion failures. 

Eclipse has a very useful mechanism for breaking on Exceptions. It's a different kind of breakpoint, which is triggered when the exception is thrown, regardless of how (and if) it is caught. If you are using assertions, I highly recommend setting a breakpoint on assertion failures when debugging your code. Here's how:

1. From the Run menu, select Add Java Exception Breakpoint...
2. Type java.lang.AssertionError in the dialog box, select the exception and click OK.

That's it, you are done. From now on, the debugger will stop whenever an exception is throw. The breakpoint will appear in the breakpoints view. You can right click it and select Breakpoint Properties... to see all the settings you can control.

The most useful feature would be to break on uncaught exceptions only, although, in case of assertions, I would break in any case.

Needless to say, the exception breakpoints can be used for any kind of exception. Truly a hidden treasure worth adding to your toolbox.

Eclipse Galileo DemoCamp in Tel Aviv

I've been dreaming about an Eclipse DemoCamp in Israel for some time now. I tried to arrange one last year for Ganymede, but with very little success. This year we are in luck, because the initiative is coming from my good friends at Zend Technologies. Zend, the company behind the immensely successful PHP language, is one of the champions of open source software. Zend actively participates in the Eclipse community, especially in two sub-projects: the Dynamic Languages Toolkit (DLTK) and PHP Development Tools (PDT). 

We have plenty of time until the planned date, June 25th, nevertheless, if you are in Israel, I invite you to sign up today and let us know you are coming. You are also invited to present a short session. 

To give you a better reason to come: I'll be giving a presentation titled "Eclipse 3.5 Hidden Treasures". Last year, I wrote an article on my blog and on Eclipse Zone titled "Eclipse 3.4 Hidden Treasures". If you google "Eclipse 3.4" this is the 4th result, the first result which is not from eclipse.org. It was one of the top 10 articles of EclipseZone in 2008. I intend to write another article for Galileo and present it at the DemoCamp. Hopefully, this year I will win the Eclipse jacket (as I should've last year, but I'm not bitter :-). 

Naturally, I will be presenting nWire, too. 

See you there.