This page last changed on Aug 28, 2006 by aperepel.

Tips for importing the Mule project and/or modules into your favorite IDE.

IDEA

Typing mvn idea:idea at the top level will create an IDEA project module with a full set of interdependent .iml files, each of those containing all the correct module references. This is extremely handy if you are an IDEA user.

It is recommended one specifies a -DjdkName="My Jdk Name" property on the command line. The jdkName is the JDK name as configured in your IDEA. Quotes are only required if there are spaces in the name. If this is not done, the project will be ok, but will require one more close/open cycle after choosing the JDK manually. With a project a size of Mule this takes a while, though.

If you add a -DdownloadSources=true option to the command, maven 2 will download javadocs and/or sources for the libraries and configure them in your IDE. 

Netbeans (using Mevenide)

It's quite easy to load the project into Netbeans using Mevenide2 for Netbeans. Just click the "Open project" toolbar action and navigate to the Mule root project directory. It allows you to open all of Mule at once or on a per project basis. You can perform either individual project builds or a higher-level, multiproject build.

Eclipse

Typing mvn eclipse:eclipse at the top level will generate the .classpath and .project files for each sub-project. You can then import them into your workspace ("Import / Existing Projects into Workspace").

If you add a -DdownloadSources=true option to the command, maven 2 will download javadocs and/or sources for the libraries and configure them in your IDE. 

Setting Your Eclipse start up parameters

You can pass a number of command-line parameters to Eclipse to alter the start up behaviour. We recommend the following options-

Parameter Description
-clean Enables clean registration of plug-in (some plug-ins do not always register themselves properly after a restart)
-nosplash Don't show eclipse or plug-in splash screens
-showLocation puts the full path of the workspace in the window title
-vm Allows you to explicitly set which JDK to use
-vmargs Allows you to pass in standard VM arguments

For example under Windows, right click your eclipse shortcut and select properties and set the Target field to something like -

C:\java\eclipsehome\eclipse\eclipse.exe -clean -nosplash -showLocation -vm C:\java\jdk1.5.0_03\bin\javaw.exe
-vmargs -Xms128m -Xmx512m -XX:MaxPermSize=128m  -Duser.language=en

Please understand that these values are only examples- in this case for a very beefy developer machine. Eclipse 3.2 uses a lot less memory than 3.1, so you  most likely need a lot less VM heap memory than -Xmx512m.

Create an external plugins location

Having your plug-ins installed outside of your eclipse installation directory means that you can share plug-ins between versions of Eclipse. There is a good blog post by Colin Sampa about how to do this.

Importing multiple projects

The Eclipse import wizard doesn't search for existing projects below 1 directory from its parent. This can be a little annoying, but luckily the Eclipse Tools project at SourceForgehas a plug-in that allows you to import all project below a parent directory. You can add the Eclipse-Tools plug-ins in the Eclipse Update Manager using this URL - http://eclipse-tools.sourceforge.net/updates/.

Once installed -

  1. Make sure Project -> Build Automatically is turned off (for now). This can speed up the entire process.
  2. Go to the menu File -> Import
  3. In the import dialog, go to the Other folder.
  4. Select Multiple Projects.
  5. Follow the on-screen prompts to import all your projects in one go.
  6. Eclipse will now take quite a while (up to several minutes) to rebuild the workspace; this is related to the Subversion plugin (if installed).
  7. If workspace reconstruction has completed, you can switch Project -> Build Automatically to on again, if you want to.

Recommended resources to ignore for team synchronisation

When you import Mule projects into your workspace, Eclipse will usually mark with a star (on a black background) resources which you might have modified. Some resources will be modified immediately by Eclipse as soon as you import the projects. This lead Eclipse to mark all projects as changed, giving you hard time to identify which resources you have really changed and which were changed by Eclipse.

This problem can be solved easily by telling Eclipse to ignore some type of resources in relation to team synchonisation. This can be done as follows:

In the menu bar, choose Window --> Preferences and a new Dialog Box will pop out. On the left hand, choose Team --> Ignored Resources and add all the patters you would like to ignore.

Some suggested patters to ignore include:
target
.settings
.classpath
.project
.mule
junit*.properties
*.log.*

Recommended Subversion config tweaks

Unless explicitly configured Subversion will not replace special keywords like $Id$, $Author$ etc. in source files at commit time. Unfortunately this setting needs to be done for each client, not on the server; for more information please refer to the section in the Subversion book about the Subversion client config file. Here are some settings to get you started - simply add the lines to the config file, either in ~/.subversion (Unix) or %APPDATA%\Subversion (Windows):

[miscellany]
enable-auto-props = yes

[auto-props]
*.c = svn:eol-style=native; svn:keywords=Id Author Date Revision
*.conf = svn:eol-style=native; svn:keywords=Id Author Date Revision
*.h = svn:eol-style=native; svn:keywords=Id Author Date Revision
*.java = svn:eol-style=native; svn:keywords=Id Author Date Revision
*.properties = svn:eol-style=native; svn:keywords=Id Author Date Revision
*.xml = svn:eol-style=native; svn:keywords=Id Author Date Revision

This will automatically be picked up by all clients that use the native (C-based) Subversion client libraries, like TortoiseSVN, Subclipse, and of course the svn command-line executable. Please note that this will only affect newly added files; existing files without the appropriate properties need to be taken care of manually.

Recommended compiler settings

The following settings are recommended in order to catch code problems as early as possible:

Settings for JDK 1.5 are not important for now; they will be updated when Mule adopts the new language features.


Document generated by Confluence on Oct 03, 2006 09:23