Mule : Working with an IDE
This page last changed on Aug 28, 2006 by aperepel.
Tips for importing the Mule project and/or modules into your favorite IDE. IDEATyping 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.
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. EclipseTyping 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").
Setting Your Eclipse start up parametersYou can pass a number of command-line parameters to Eclipse to alter the start up behaviour. We recommend the following options-
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 locationHaving 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 projectsThe 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 -
Recommended resources to ignore for team synchronisationWhen 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: Recommended Subversion config tweaksUnless 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 settingsThe 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 |