How to Migrate from Ant to Maven: Project Structure
I’ve seen my fair share of projects migrating from Ant to Maven, and, for a complex project, this migration path can take some time. You have to worry about dependency management, project structure, and retraining an existing team to use Maven and understand the core concepts behind the tool. When you make the shift, you are often affecting development infrastructure for an existing project, and you need to take into account development environments as well as developer’s ideas about how code should be organized and stored in source control. In this post, I’m going to discuss a common pattern I’ve seen in Ant to Maven migrations: how to migrate the monolithic project.
Benefits of a Repository Manager: Part III Continuous Build Deployment
In the previous post in this series I discussed three compelling ways in which a repository manager can benefit the development cycle. It proxies artifacts locally, it is optimized to store binary artifacts, and it facilitates a new level of collaboration and agility that isn’t possible when your SCM is only way for workgroups to collaborate. In this post, I’m going to talk about how a repository manager works in concert with a continuous integration server like Hudson or Bamboo.
Roller Project Converts Build to Maven
Sonatype has spent the last few years investing in the Maven ecosystem. We’ve created solid documentation, we’ve invested heavily in making sure that m2eclipse provides solid IDE integration, and we’re about to unleash even more tools that will make it even easier for developers to develop and share software. Here’s an excerpt from Dave Johnson’s entry on converting the Roller project’s build to Maven:
I was a Maven hater and resisted it for a long time but over the years Maven has gotten much better, it’s well supported in IDEs and as far as I can tell, Maven has replaced Ant as the de facto build system for Java projects. If you want new developers be able to easily build, debug and run your code via command or their favorite IDE then Maven is the way to go, and that’s especially true for open source projects like Roller. That’s why I spent a couple of weekends learning Maven and converting Roller’s build process from Ant to Maven (ROL-1849). The process of conversion wasn’t too difficult.
Maven over Ant + Ivy: A Team Perspective by Les Hazlewood
Les Hazlewood has an objective summary of why he eventually came around to deciding that Maven is a better overall solution then Ant + Ivy. This is an evolution in thought process that we, Sonatype, often see in enterprises and Les has two blog entries that illustrate this evolution perfectly.
Maven 2 vs Ant+Ivy: Our selection process: This entry gives Les’ original perspective on Maven and the process by which he originally decided to choose Ant + Ivy.
Maven 2 vs Ant+Ivy: Revisited: This entry gives Les’ new perspective and why his enterprise team, and the Apache Shiro project, have chosen Maven.
I now firmly believe that Maven 2 is a better build and project management tool than Ant+Ivy. I was wrong.
Yep, I said it. I’m man enough to admit when I’ve made mistakes and that I’ve learned from my experiences. And this is coming from the guy that wrote a (still popular) OnJava article for Ant in the enterprise.
Overall, life with Maven is good. I’m glad that I was able to swallow my pride, really give it a chance, and in turn reap the benefits. I haven’t used Ant in over a year since switching, nor have I ever felt the need to go back.
We hope this perspective helps potential enterprises save time when looking for a build and release infrastructure.
OpenDocument Java API Project Switches from Ant to Maven
ODFDOM, the OpenDocument Java API, has been released. You can read more about the project release here. From the site: “ODFDOM is an Apache 2 licensed Java library to easily create, access and manipulate ODF documents.” What’s interesting about this particular software release is the switch from Ant to Maven. Here’s the quote that caught my attention.
Last but not least, with the support by Benson Margulies, we were able to switch our build environment from ANT to Maven. By using Maven we made our dependencies declarative. We no longer add dependent JARs to our sources (e.g. the parser XercesImpl.jar), but are able to download them via Maven [Central] on demand. Following this idea of modularization, we were able to simplify the source structure of ODFDOM by moving our code-generation to a [new] project called relaxng2template.
