Not a single vote claiming that he/she will never install an unsigned plugin.

79 people voted, out of 727 reads for the article. That's almost 11%. For comparison, the poll on XML handling got about 13% participation. That's almost 20% more. As I see it: people that don't care are less inclined to vote. People who oppose will likely vote, to have their strong opinion heard.

My conclusion: don't bother because people don't care.

If you still going to sign your code, go with Peter's tip and buy the certificate from Tucows. At $75, they seem to be the cheapest around and you get exactly the same certificate (they buy them in bulk...).

I still think there's a point in keeping the unsigned warning when installing such a plugin. Some people will check the origin to make sure it is bona fide. But then, again, I've never heard of a malicious Eclipse plugin. I guess there's always a first time...

May 11, 2010

Here's a definition from Wikipedia: "Code signing can provide several valuable features. The most common use of code signing is to provide security when deploying; in some languages, it can also be used to help prevent namespace conflicts. Almost every code signing implementation will provide some sort of digital signature mechanism to verify the identity of the author or build system, and a checksum to verify that the object has not been modified. It can also be used to provide versioning information about an object or to store other meta data about an object."

In Java, JARs can be signed using a certificate. Much like SSL, you need to buy those certificates. However, these certificates are more expensive, starting at about $200 per year. Although it is not a lot of money, I'm having a hard time justifying the efforts involved.

The knowledgeable reader might say that this is a major issue in large corporate environments. Just to demonstrate: Eclipse 3.3 warned the user when installing unsigned plugins. In Eclipse 3.4, this warning was completely gone. Poof. Vanished. Yet, Eclipse 3.4 was used in large corporate environments. Fear not, the warning was back in Eclipse 3.5, after someone cared enough (read: was ****** enough) to open a bug about it (if you wonder who, you can look it up).

Oct 27, 2009

I wrote twoarticles on this issue in the past and I'm still get a lot of search hits everyday for people searching for answers, which means it is still a hot topic. Things changed a bit since I wrote the articles, so it's worth bringing this update.

The purpose of this post is to help you make the best selection and install it properly. It applies to all the Eclipse packages, including Java, JEE, PHP and C++. I did my best to assume little knowledge with Eclipse. If you still have questions, please ask in the comments.

Leopard (10.5.x) Users

Download the Mac Cocoa 32-Bit version.

The Carbon version is there in case you encounter compatibility issues with older plugins. The 64-Bit is there in case you need to run a plugin which requires Java 1.6, since Leopard Java 1.6 is only 64-Bit. Otherwise, I don't see a real reason to use it (although not everybody agrees) and you will be wasting RAM and machine resources.

Snow Leopard (10.6.x) Users

Download the Mac Cocoa 64-Bit version.

Again, the Carbon version is there in case you encounter compatibility issues with older plugins. The main reason you would want to use the 32-Bit version is because of plugins which are incompatible with 64-Bit. This time, the 32-Bit version will waste your resources because you will cause the OS to start a whole bunch of 32-Bit services.

The 64-Bit Eclipse will consume more memory than a 32-Bit Eclipse of Leopard. There's a small tweak you can use to reduce the memory consumption of the 64-Bit Eclipse: add the UseCompressedOops flag to the Eclipse JVM. Here's how:

Under Contents/MacOS, locate the eclipse.ini file. Open it with a text editor.

At the end of the file, add two lines:-XX:+UseParallelGC-XX:+UseCompressedOops

Save and close the file.

Full explanation on the UseCompressedOops switch can be found here. Note that this option may not be the most stable: if you experience crashes, remove it.

Installing Eclipse

After you downloaded Eclipse and untar/ungzip it, you will get a folder called eclipse. Several people asked my what's the best practice for installing Eclipse. Eclipse is a bit different than other Mac applications. It needs to stay in the same folder with all the files that came along with it. So, naturally, installing the Eclipse.app directly in your Applications folder is a bad idea.

Note that there's no limitation on the number of Eclipse installations you can have in this Dev folder. For example, I have both Eclipse 3.4 and 3.5 installed. I even have Eclipse 3.5 Carbon which I use for testing. You can rename the eclipse folder after unzipping the downloaded zip: I usually use the full name of the zip (sans the suffix) as the name of the folder.

Your Workspace

The default Eclipse distribution will ask you for a workspace by default. I have a number of workspaces and I switch between them. I keep my workspaces under ~/dev/workspaces/<my workspace>

Final Thoughts

Installing Eclipse on Mac OS X is a simple task. If you want to simplify it even further, including ease the installation of Plugins (like nWire :-), I suggest looking into a more user friendly and powerful distribution like Pulse.

Oct 07, 2009

The following post outline a suggestion for a new Eclipse feature which will make it easier to download and install Eclipse plugins. If you like this suggestion please vote for this bug. Comments and further suggestions may be posted here or in the bug itself.

Here's a common scenario: you are surfing the web, and then, out of the blue, you come across this incredibly interesting tool. You decide to give it a go. What will you do next?

If it is a web application, you would probably signup. If it is a desktop application, you would download it. It turns out that most people will not install it right away. You are now browsing the web: searching for answers, reading articles or just enjoying some leisure time. You are not interested in breaking your concentration and start fiddling with installations.

Eclipse plugins, however, are different. The best way to install Eclipse plugins is using the built in update manager by providing an update site URL. Instead of downloading the software you are left with an update site URL. If you are not going to install the software right away, what will you do? write it on a piece of paper? bookmark it for later? The odds are that you will forget about it a couple of hours later and never install it anyway.

It's a key element in selling software: People who decide to try desktop software should be left with something very tangible: a downloaded file.

Oh, and all you open source developers reading this, trust me: you want to "sell" your software too. There's nothing more rewarding than having people using your software. You won't get money but you will get recognition and gratitude. We are on the same page.

There is an existing option of using the "Dropins" folder. I would bet that most people who use Eclipse or Eclipse based IDEs don't even know these droppings (sorry, couldn't resist) exist. It is not common knowledge when it comes to Eclipse (people working on the platform for a long time tend to forget that).

The Proposal: A New Eclipse File Format

A new Eclipse downloadable file format is introduced. The files will have a unique extension which is associated with Eclipse. Upon double clicking a file in the operating system, Eclipse will receive an open event for the file, much like other OS applications.

The format itself will be a JAR with a different extension (much like WAR and EAR). There are several options as for the contents of this JAR:

A URL of an update site. The URL could be in the manifest or in a dedicated resource bundle file. Upon launching the file, Eclipse will automatically add the site and start an installation process. One may think of more advanced options to include other than the URL, e.g. the feature name to install, which will transparently select the feature and move on the installation phase.

An archived update site. Operates much like the remote installation, but uses the local archive. It would be nice to add an option to check for newer versions.

One may take this one step further and allow the file to contain a complete OSGi bundle. Upon launching the file, the platform will automatically install the bundle and start it, enabling developers to develop custom installers and plugins which will not require any installation (for example, you want to do something just once).

The platform should protect against malicious content, check for code signing and confirm with the user before executing the code, much like it is done today with downloaded content in Windows and OS X.

Future plugin updates will use the current Eclipse update mechanism, although it could be possible to download a newer version of the plugin and install it in the same easy manner.

The result: Installable plugins may be downloaded from web sites. The installation process is a simple process as it is will all applications today: double click to execute the installer, receive an installation UI and complete the installation.

IMHO, the main challenge is associating the platform with the file. For example, I have at least a dozen different Eclipse instances on my machine. Which one is loaded upon double clicking such a file? Well, each OS has a way of handling these file associations and there should be a preferences page for defining which is the Eclipse installation which receives the file open events by default, unless a different platform is already open. Handling the case of multiple running platform also seems simple enough.

Sep 07, 2009

When we first launched the original nWire, which provided code exploration for Java, we knew that adding support for more languages was just a matter of time. With the support of the Zend Studio team, which is also leading the development of the Eclipse PDT (PHP Development Tools) we are now proud to present nWire for PHP.

nWire for PHP is an Eclipse plugin which accelerates PHP development by
helping developers navigate through their code and better understand
the architecture of their application. nWire was designed for
developers who get lost in large and complex applications. It
dramatically shortens the time it takes to read and understand the code
and reduces the learning curve for new developers.

nWire Navigator - a unique tool for browsing any type of association in the application code: type inheritance, file inclusion, method invocation and more - all in one central view. This view can be synced with the PHP code editor and provide instant context while browsing the code.

nWire Quick Search - search as you type for any element in the system, including methods and fields. Once a relevant component is found, a single click will reveal all its' associated components.

nWire Visualizer - graphically browse the system elements and visualize the associations between them. Filter the associations to produce different types of graphs. Exported images are a great enhancement for code reviews and documentation.

nWire is based on static code analysis. True, analyzing a dynamic and weakly typed language like PHP cannot be complete. Nevertheless, we have some interesting solutions for the dynamic nature of PHP. nWire can even analyze the PHP-Doc comments for associations like field types.

nWire for PHP is available today at an introductory price of $59 for a perpetual license (volume discounts available). A free (and risk-free), 30 day trial is available on our site. It can also work side-by-side with nWire for Java.