• Bug 367461 - [mt4e] mt4e needs priming.zip
• Bug 354381 - Error: groovy.lang.MissingPropertyException: No such property: args for class: m4e.ImportTool

Have Fun!

A good example are Maven (mvn install) or most automake builds (configure && make && make install). They usually just work and if they fail, they give you some context to work from.

A good negative example are Eclipse PDE builds: Often there is no build script. If there is a build script, it will fail with an obscure error message in an Ant script that was recursively called by about 100 other Ant scripts. Each Eclipse project uses PDE but each build has different prerequisites (which you must know). If the build uses p2 repositories, there is no way of telling whether two subsequent builds will produce the same result. Some projects try really hard to help newcomers to build their stuff with a recipe that needs 100+ easy steps. In four words: It’s a mess.

Or a surefire way to attract only the most dedicated committers because everyone else will be utterly demotivated very quickly (and you don’t want those, do you?

So like Dave Carver, I would like to spread the idea. Make builds more simple. Here is an example and following Dave’s advice, I’m going to make the build script even more simple.

Why a script and not, say, a web site with instructions? Several reasons:

1. A script will make you more dedicated. It’s easy to be sloppy with a README. With a script, at least the syntax will be right.
2. When a README fails, you won’t really know what to do next. With a script, you have a very precise starting point for a bug report: “The setup script failed in line 15″ vs. “Install with Maven … and which version?”
3. Scripts can prepare the environment. Since you don’t want to make anyone angry, create a new directory and put everything in there. Download what you need, unpack it, configure it. If you can’t do it with a script, why should a newcomer fare better?
4. Can’t download something? You can always print an error message with exact instructions: Go to website … download xxx, version yyy … put it here. In a script, you can say ‘echo “Put download into $build_dir”‘ Try that in a README.
5. You can prove that a script works. Good luck trying that with a README.
6. You can run scripts on a CI server to make sure they work.
7. A script always needs an interpreter. Bash scripts run on Mac and Linux. What about Windows users? Well, 100% of the Windows users build OSS software from .msi files. The tiny rest has three options: a) Read the bash script, b) install Cygwin/MinGW, c) install Linux.

Here are some tips to speed up the process a lot:

1. If Eclipse still works, export your preferences.
2. Install the Bulk Import plugin to save list of projects and their state.
3. Instead of deleting .metadata/, rename it.
4. Restore the folder “.metadata/.plugins/org.eclipse.core.runtime/.settings” from the backup. This is basically the same as the preferences. Kudos to Tomas Kramar for figuring that one out.
5. Restart Eclipse. You should get an empty workspace but all your preferences should be there.
6. Use the buttons in the toolbar to restore all your projects.

Another useful plugin is the “save UI state” which saves the workspace layout and open editors after every change (based on the code here).

With a way to preserve your preferences, saving the project state the workspace layout, you should be able to quickly restore the IDE.

Related articles:

• Eclipse Dance Steps – “Sometime Eclipse fails to work as expected. The following ‘dances’, in increasing order of desperation, may help. Remember to maintain a fixed grin throughout and try not to tread on your own toes.”

I just finished a new release of Maven Tools 4 Eclipse. It’s not written in Groovy and supports all the features of the old Python version plus a few new ones.

You can find instructions how to use it on the wiki page.

For now, you need to build the tool from source (which needs 1.4-SNAPSHOT from DecentXML) using Maven. I’m in discussion with the people at Eclipse to get a download link for the binary.

Update: The project page now has a download link.

If you’re on Ubuntu, you can replace the “mercurial” package with “mercurial-1.8″ to get the old version back (see Launchpad packages). Thanks go to Max Bowsher for a quick solution:

sudo aptitude install mercurial-1.8

Workarounds:

1. Close Eclipse when you build your projects with Maven from the command line
2. Disable automatic refresh (Preferences -> General -> Workspace -> Refresh using native hooks or polling)

And I’ve started to convert the tools from Python to Groovy.

Don’t worry, it’s part of the Indigo release train. Just install it manually from the Indigo p2 repository: http://download.eclipse.org/releases/indigo

Links: Oh my god, but where is m2e?