Introducing eclipse to maven

Converting a single Eclipse project to Maven is a small task but it becomes huge when you have to deal with hundreds of Eclipse projects. Again this is common in large enterprises. In this context, it can be very useful to have a tool which does just that. The eclipse-to-maven project on github has been created for this purpose.

In current shape it has following features:

• Converts .classpath files into pom.xml.
• Moves source folders according to Maven convention. For instance Java sources go to src/main/java folder.
• Removes spaces in the names of the folders, e.g. “Calculator Component” becomes “CalculatorComponent”.
• Right now Mavenisation is limited to generating dependencies in the pom. However this is a great first step in pom generation. With small changes you can run the Maven build for your projects.

Though software world has already moved on with latest technology developments, many projects in big enterprises are still running on old technologies. In large enterprises technology selection and change is still a big issue just because it comes with a cost of maintaining hundreds of software applications. If they don’t select and limit technologies properly, they can be in big complex soup.

Changing technologies swiftly can be one extreme and another extreme can be not changing anything at all. This eventually may mean huge time taken in introducing any new feature in legacy software. Maintenance also becomes big headache. So though it’s okay doing technology selection properly, it’s important also to adapt with changing environment and continuously ensuring the quality improvement.

In current context, I am talking about Maven-ising the existing Eclipse workspace. Maven is important step in build automation and is a high level build language compared to Ant. Adding new quality features in Maven is just a matter of few line changes.

Maven is convention based build approach where project structure is consistent across. So instead of looking for new source folders and adapting the build script accordingly, Maven knows the default project structure which is all it needs.

Eclipse workspace can have various issues such as:

• No specific source folders. Any folder can be a source folder which forces build scripts to adapt accordingly. In long run it’s a huge waste
• Eclipse projects having names containing spaces for instance “Calculator Component”. It can be very difficult to work with these folders in Linux/Unix environments.
• No consistency in having test-cases and their specific folders in the projects
• No difference between test-cases related dependency and main build dependencies. So all jars eventually become part of the end product (war or ear file).

Let’s see how much Maven-ising existing Eclipse projects to Maven is useful.

• Maven works on the “Convention Over Configuration” concept in which systems, libraries, and frameworks should assume reasonable defaults. Without requiring unnecessary configuration, systems should “just work”.
• As you don’t have to worry about configuration anymore, you can focus your energies in doing the actual real stuff which again doesn’t remain a big deal
• Maven comes with a lot of plugins. Instead of creating things from the scratch, you can be rest assured as majority of the requirements have already been implemented as Maven plugins and all you have to do is to just write few lines of XML in your pom and you are done.
• When it comes to using plugins, there are many plugins available which help a lot in quality improvements and assessing the existing code quality. The plugins like cobertura, surefire (comes as default), sonar, checkstyle and PMD are invaluable. These quality tools can be integrated with Continuous Integration tools. So for instance your code coverage drops below a threshold (e.g. 75%), the build will break and notification will be sent to the team.
• Not to mention build becomes single click