Every efficient software development team should have a common easy deployable IDE which  can be installed and reinstalled in a simple way. There are several good reasons for this. Some of them:

1. Minimizing the configuration cost: Configuring an IDE for an average or big project is a time and resource consuming process. By creating a deployable common IDE  it is possible to minimize the cost by reinstalling the IDE when something is going wrong after a while. With other words: don’t lose time to fix it, start it over instead.
2. The new developers will be able to gain insight into the code directly and they don’t need to face the configuration problems while preparing an IDE.
3. Using the same version of IDE, libraries and the programming language leads to  better standards and code quality. All developers will be familiar with common problems caused by version incompatibility and can help each other. They will see the same set of warnings and errors by using the same compiler version and can have the same policy toward them.
4. It is possible to define the same set of preferences for IDE and same code formatting’s policy.  It will help developers to keep standards high.

Rest of this post will describe a process for preparing eclipse as a common shared IDE shared by a developing team.

1. Choose a path which all developers will install Eclipse and JDK to it. It will be better to keep JDK and Eclipse at same folder.  “C:\Programs\companyName\DevEnv” will be used as example here.
2. Deploy the chosen JDK into above folder path. It should be a JDK that you can compile your code with it.
3. Download the preferred  version of Eclipse. While writing this post the download site was  http://www.eclipse.org/downloads/.
4. Unzip the downloaded file to the chosen folder path. Don’t try to start Eclipse! Starting eclipse for first time will create some local configurations that other developers don’t need it. Name the unzipped folder to NoneStartedEclipse_XX which XX is the eclipse version.
5. 1. It is a good practice to name the version of Eclipe and JDK in respective folder name. In the below structure XX respective YY are Eclipse and JDK versions.

   -C:

        – Programs

                        -comanyName

                                              – DevEnv

                                                            – NoneStartedEclipse_XX

                                                            -JDK_YY

6. The next step is to refer to JDK in the “eclipse.ini” file. Open the “eclipse.ini” file under  “C:\Programs\companyName\DevEnv\NoneStartedEclipse_XX” and add these two rows:
   

   -vm

   C:/Programs/companyName/DevEnv/JDK_YY/bin/javaw.exe

7. Other arguments related to JVM can be defined in “eclipse.ini” file too. If developers have enough memory on their machines and you are using eclipse 64 bits version then you should specify the minimum and maximum size of the memory allocation pool (-Xms, -Xmx) to use the abilities for eclipse 64 bits version. It is good practice to set the both Xms and Xmx to the same value. In this case Java heap memory size error will be found at start of Eclipse if there is no enough memory on the machine.

   Another JVM-related argument is the required java version. You can redefine this argument to force developers to use a higher version of Java than the default version. Before you can see an example of these arguments.

    -vmargs

   -Dosgi.requiredJavaVersion=1.6

   -Xms4096m

   -Xmx4096m

8.  Next step is the configuration of the proxy settings. If your company are using a proxy server you should configure it in Eclipse for connecting to Eclipse Marketplace or downloading extra plugins. For this purpose you should create a file named “org.eclipse.core.net.prefs” under this path: “C:/Programs/companyName/DevEnv/NoneStartedEclipse_XX/configuration/.settings”. The file will be created automatically first time starting eclipse but because other information created by first start of eclipse are unnecessary for all developers you can create this file manually. You should create “.settings” folder manually too.  If you are using windows it will not allow you to change the name of the new folder too “.settings” because of the dot (“.”) in the beginning. You can copy the folder from an old eclipse version and empty it or you can use Windows commando and MD-command to create the folder. An example of the content of  “org.eclipse.core.net.prefs”:

eclipse.preferences.version=1

nonProxiedHosts=jira.company.com|localhost|127.0.0.1

org.eclipse.core.net.hasMigrated=true

proxyData/HTTP/hasAuth=false

proxyData/HTTP/host=PROXY.COPANY.COM

proxyData/HTTP/port=8080

systemProxiesEnabled=false

NonproxiedHosts at above are exceptions from proxy server and will be accessed directly. A good example is issue-tracking systems like Jira.  The most important arguments in the file are the name of proxy server (proxyData/HTTP/host) and the proxy port (proxyData/HTTP/port).

9. After configuring proxy can you install needed plugins.The below steps can be taken for this purpose.

I.  Copy NonStartedEclipse_XX folder to a new folder named StartedEclipse_XX. Run “eclipse.exe” under this folder. Use an empty workspace for starting eclipse. Close eclipse and compare these two folders (NonStartedEclipse_XX and StartedEclipse_XX). You are going to find out what information are added to eclipse folder by starting eclipse for first time.

Some of this new added information are local and should not be added to a common IDE using by whole team. But removing some of these information will cause in damaging eclipse. Later you will see a list of the folders which you can remove after installing plugins to prevent other developers to get local information when they are installing the configured IDE.

II. Create a readme text file under “C:/Programs/companyName/DevEnv/” and write in it the version of eclipse and JDK. You should document every plugin you are installing and its version in this file too. Here is a example of this file’s content:

The zip-file contains:

–    Eclipse Kepler                     4.3 (64 bit)

–    JDK 1.7.0_2                        (64 bit)

Plugins:

–    Eclipse Standard/SDK                                  2.0.0.20130602-1703

–    Eclipse SDK                                                  4.3.0.I20130605-20000

–    Memory Analyzer                                         1.3.0.201305170842

–    Memory Analyzer (Charts)                           1.3.0.201305170842

–    Graphical Editing Framework GEF              3.9.0.201305060205

–    Graphical Editing Framework GEF SDK     3.9.0.201305060205

–    Eclipse XSL Developer Tools                      1.3.300.v201302282018

 III.  Some plugins like version control system are chosen by your companies policy. Other can be chosen by your applications need. T.ex. if you are developing an Eclipce plugin; maybe you are using GEF for drawing, then you should install GEF plugin. The other plugins can be some useful plugins for developing like code analyze, Memory analyzer and so on.

There are different ways for installing plugins. Some of them can be installed via “Install new software” option in eclipse help menu. You can find a bunch of useful plugins under eclipse standard update site. The picture below shows installing memory analyzer under “General Purpose Tool”-category of Eclipse kepler’s  standard update site.

Some of plugins in eclipse standard update site are uncategorized and if you want to find them in the update site you should remove the check mark from the check box “Group item by category” on the above window.

Some of plugins require to be add using a new update site. T.ex. Graphical Editing Framework can be installed by adding this update site to the eclipse update sites. (Adding an update site can be done using the “Add…” button in the above window.

Some of the plugins can be installed by Eclipse Marketplace. You can find Marketplace under Eclipse help menu. In some eclipse editions Marketplace plugin are not installed by default.  Then you can install it via eclipse standard update site. The below picture shows installing findbugs plugin via Eclipse Marketplace.

One of the problem with marketplace is that that it takes time until the last version of a plugin is available via the marketplace. It can happen that a new version of a plugin is represented on the plugin’s update site but the marketplace is yet referring to an old version of plugin which maybe not be compatible with last Eclipse version. The other problem is that that some plugins cannot be installed via the marketplace (there is no Install button for them). Therefore it is a good practice to check the last version of plugin via the plugin’s  homepage before updating it via Eclipse marketplace. For doing this you can click on the “more info” link for the plugin and then choosing “learn more”. You will be redirected to the plugin’s webpage on the marketplace. As shown on the below figure.On the plugin’s webpage on the marketplace you can choose home icon to go to the plugin’s official webpage and check the last version of plugin there. You can check if the update site has been given in the official plugin’s webpage is the same as the update site has been given in the plugin’s homepage on the Eclipse marketplace. The update site on the plugin’s homepage on the Eclipse marketplace can be found by clicking on the green down arrow. See the below picture.

IV.  You can see a list of useful plugins below.

• You should control if you need to install a plugin for your source control system.
• Memory Analyzer and   Memory Analyzer (Charts)  for checking the heap. Both of them can be got from Eclipse standard update site.
• Find bugs for  static analysis to look for bugs in Java code. Can be downloaded from eclipse marketplace.
•     Eclipse XML Editors and Tools and    Eclipse XSL Developer Tools. Working with XML and XSL nowadays is a part of a developers everyday job. Eclipse plugins for XML and XSL are useful tools while working with xml files in Eclipse. Both can be downloaded via Eclipse standard update site.
• Atlassian connector for Eclipse. If it has support for your issue tracking system.
• EclEmma Java Code Coverage is a good help for writing better unit tests.
• SWTBot for UI testing in Eclipse and SWT. If you are writing eclipse plugins.
• Eclipse Core Tools  (http://www.eclipse.org/eclipse/platform-core/downloads.php#updates) even they are not updated for a while it is possible to find dead code in Java with its help.
• CodePro Analytix  (https://developers.google.com/java-dev-tools/download-codepro)  Googles plugin for code analyze.

10.  After you are finished with installing plugins you can remove unnecessary local configuration From StartedEclipse folder as mentioned in 9.I in this post. You can remove the below files and folders:

• C:\Programs\companyName\DevEnv\StartedEclipse_XX\configuration\.sttings\org.eclipse.ui.ide.prefs
• C:\Programs\companyName\DevEnv\StartedEclipse_XX\configuration\ org.eclipse.core.runtime is used to refer to local workspace and should be removed.
• C:\Programs\companyName\DevEnv\StartedEclipse_XX\configuration\ org.eclipse.e4.ui.css.swt.theme
• C:\Programs\companyName\DevEnv\StartedEclipse_XX\configuration\ org.eclipse.equinox.app
• C:\Programs\companyName\DevEnv\StartedEclipse_XX\configuration\ org.eclipse.osgi
• C:\Programs\companyName\DevEnv\StartedEclipse_XX\configuration\ org.eclipse.ui.intro.universal

11.  You should test your development environment before the other developers are going to use it. Copy the StartedEclipse_XX to the same path and change the name to TestingEclipse_XX. Start the copied eclipse toward an empty workspace.

• Import your projects to the new workspace.
• If you need to run some scripts for preparing your code to be compiled (T.ex. scripts for generating code from xml files) do this. You should not have any compilation error.
• Connect your projects to the source control system and if you are using Atlassian connector, connect it to your issue tracking system. Check if you can do usual operations as checkout, activating issues and so on.
• Check if all of the needed GUI-features are existing. T.ex. Search, build and so on. Check the list of perspective and views too.
• Build your application and run all types of your test. You should run all of them without problem.
• Deploy or install the built application and check if it works.
• If your team have other scripts and operations that are being used by developers frequently you should test them too.
• Check the plugins you are installed to control if they are working properly.

12.   If everything was OK on the before step you can define a set of common preferences for eclipse to be shared between developers. For this purpose you can define a plugin_customazation.ini file under your eclipse installation (StartedEclipse_XX folder).  You should add a line to your “eclipse.ini” file referring to the plugin customization file. T.ex. the below line:

-plugincustomization

plugin_customization.ini

 Below can you see some examples of prefrences:

Activating most of Java warnings is a useful and increases code quality. You can see some java related preferences.

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.7

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.compliance=1.7

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.annotationSuperInterface=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.assertIdentifier=error

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.autoboxing=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.emptyStatement=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.enumIdentifier=error

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.explicitlyClosedAutoCloseable=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.fallthroughCase=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.fieldHiding=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.indirectStaticAccess=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.localVariableHiding=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.missingDefaultCase=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.missingHashCodeMethod=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.missingOverrideAnnotation=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.missingSynchronizedOnInheritedMethod=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.parameterAssignment=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.possibleAccidentalBooleanAssignment=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.potentialNullReference=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.potentiallyUnclosedCloseable=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.redundantNullCheck=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.redundantSpecificationOfTypeArguments=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.redundantSuperinterface=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.reportMethodCanBePotentiallyStatic=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.reportMethodCanBeStatic=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.syntheticAccessEmulation=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.undocumentedEmptyBlock=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.unhandledWarningToken=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.unnecessaryElse=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.unnecessaryTypeCheck=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.unqualifiedFieldAccess=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.unusedDeclaredThrownException=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.unusedObjectAllocation=warning

org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.problem.unusedParameter=warning

You  can activate  ant warnings too:

org.eclipse.ant.ui/problem_imports=warning

org.eclipse.ant.ui/problem_properties=warning

org.eclipse.ant.ui/problem_security=warning

org.eclipse.ant.ui/problem_tasks=warning

 

Another good preferences is showing line numbers in editors.

org.eclipse.ui.editors/lineNumberRuler=true

A way to find out preferences is to start your testing eclipse with an empty workspace. Then close the eclipse and save the workspace somewhere else. Start eclipse again and in the windows menu select the preferences and change them to values you want. Close the eclipse. Compare changed workspace with the saved workspace. Most of the time you can find the new preferences under below path under your workspace.  “metadata\.plugins\org.eclipse.core.runtime\.settings\”.

You can just copy and paste preferences to  “plugin_customazation.ini” file. As you see on the examples above you should write the name of respective plugin before the preferences key. The name of plugin is the same as the file name under “.metadata\.plugins\org.eclipse.core.runtime\.settings\” folder under workspace without the “.prefs”-extension.

13.  Rename StartedEclipse_XX to Eclipse_XX and zip it together with readme.txt and JDK  in the same file. Put the file somewhere on the companies intranet. Write an script that copies the zip file from the intranet and unzips it to “C:\Programs\companyName\DevEnv”. The developing environment is ready to be used by the team.