-
Notifications
You must be signed in to change notification settings - Fork 14
Why eclipse to maven?
Through this post, I would like to analyse the factors on why to mavenise the existing Eclipse based workspace using eclipse-to-maven project.
ANT is a low level language and requires everything to be created from the scratch. The main focus remains creating build for the project. With Maven, build becomes trivial and you start focusing on bigger goals like enforcing test coverage, static code review with checkstyle and PMD. That too becomes very simple as many of the plugins are already available.
Provides a good time to restructure and having a thoughtful analysis on what kind of sources should be placed where. The analysis results in potentially removing cyclic dependencies, identifying the sources which are not used anymore. This in turn results in reducing the build time significantly.
In order to be continuous delivery ready, the build has to be single click (virgin machine with just Java in place), continuous integration ready all the time, plugins available to support automated functional testing. Also build should be simple enough to introduce any new small or big build specific change. Maven is a first step towards doing that in any Java based workspace.
- It’s evident that code without tests is fragile to the changes as every change require good amount of manual regression tests to run.
- Developers feel insecure while making the changes in the code as without tests, you absolutely have no idea what could potentially break with your changes.
- Continuous delivery suffers as though development time may be 2-3 weeks, the whole regression may take 3-4 weeks or maybe less. But combined effort becomes a costly and time-consuming affair. You may wonder why some couple of classes change require the whole month before something could be moved to production.
- With Maven you can have proactive quality checks (build fails if your test coverage goes below threshold for instance) instead of passive ones (generating reports).
ANT is a low level language. Though it provides the flexibility but that comes at a cost of creating everything from scratch. That means, build scripts have to be project specific and not standard. Build scripts become complex and require specialized skills to work with. Not everybody in the team will have all necessary skills to make changes in it. That impedes the efficiency of team.
Maven on the other hand is a high level build language. For most of the general needs, developer community has created maven plug-ins. So instead of reinventing the wheel with ANT and filling a lot of build script pages, plug-ins require just few lines of change. This in turn makes simple enough that any team-member can potentially make changes to it without having a lot of past context.
As eclipse based build requires all jars including test specific jars like junit, hsqldb, the resultant artifacts will be bigger in size. As Maven selectively builds for main artifacts and tests, the size of the resultant artifact remains smaller. This may help in loading the application in smaller memory based device, machine.
People who work with Eclipse must be aware about the kind of mess transitive dependencies create. For instance your project depends on xerces.jar which implicitly depends on yet another jar. While adding the dependency with Eclipse build path, you may not be aware if it depends on any other jar. You get to know about it only at the run time when you see ClassNotFoundException. Now you add that jar and you again find that it depends on yet another jar. This is frustrating as transitive dependency resolution is manual in this case. With Maven this is automatic as every dependency knows its dependencies through its pom. For a developer, it’s just relaxed time.