News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
ASP.NET MVC 2 Ships
ASP.NET MVC 2 has shipped.
03/12/2010 10:26 AM EST

Microsoft plans 'open' Silverlight analytics framework
Microsoft is going to announce a multipurpose analytics framework for Silverlight at MIX.
03/11/2010 09:51 AM EST

About CSS processing
Two sites that lead to a startling CSS conclusion.
03/10/2010 02:29 AM EST

 

Events calendar tab
3/14/2010 to 3/18/2010
Seattle, Wa.
SHARE

3/15/2010 to 3/18/2010
Santa Clara, Calif.
TechWeb

3/15/2010 to 3/17/2010
Las Vegas
Microsoft

3/16/2010 to 3/19/2010
Las Vegas
Penton Media

3/17/2010 to 3/19/2010
Las Vegas
TechTarget


 
Most Read Latest News Blog Resources

Andrew Binstock: From Ant to Maven




October 15, 2007 — 
During the past month, I have been doing what increasing numbers of developers are urging their peers to do: move projects from Ant to Maven 2. In my July 1 column, I discussed my mounting frustrations with Ant (“Moving Past Ant,” www.sdtimes.com/article/column-20070701-04.html). When I finally was no longer motivated to soldier on with Ant’s minimal delivery model, I finally put the time in to make the switch to Maven. I’m glad I did. There is lots to like about Maven.

Most visible is that Maven has a vision of a build cycle that consists of a sequence of commonly performed build steps. You indicate what you want done in certain steps, and that’s it. Maven has intelligent default behavior for the other steps, so the results tend to be what you expect. This build model enables Maven to embrace the paradigm of “convention over configuration” that was made famous by Ruby on Rails. With Maven, you roll with the basic model, making only small tweaks for project-dependent steps, rather than configuring every step in detail for Ant. Ant is more like the venerable make tool, which simply follows orders and serves as a meta-level task execution language.

The Maven model also has a useful end result in addition to the built project: a Web site with the reports generated by the various build steps. Maven creates a Web site with menu picks that reflect not only reports on standard operations, but any other documents or reports you request. For example, place a JDepend command in Maven to see the dependencies between packages in your Java project, and the results are displayed in an HTML report on your Maven Web site. Because of this, your project Web site as created by Maven always reflects the latest status of your project. Stick it on your developer intranet, and all team members know exactly where things stand.

This comes tantalizingly close to what is thought of as continuous integration (CI). However, it lacks a few crucial elements that CI provides: It does not monitor source-code repositories for any modification that could start up the build process, and it does not keep historical data on previous builds—the generated Web site is a single time slice. But if you add monitoring and history to Maven, you would have a barebones CI system. Because of this proximity, most CI systems support Maven 2.

Maven has another very convenient feature. When you ask it to run a utility (such as one of the many code checkers available), it knows how to find and download the utility and how to download the libraries and resources the utility requires. Picking up my previous example of JDepend: Maven downloaded all the needed pieces and stored them in its local repository and then generated the JDepend report.

Ant, by comparison, refused to run JDepend and instead issued a warning that it could not find a needed JAR file. This feature can also be leveraged by sites to make sure that they are always building with the latest versions of tools. (Predictably, this update feature can be overwritten.)

The migration from Ant to Maven is not hard. The central file for both uses XML (alas). And the specification of options for specific jobs will look familiar. However, Maven does expect a certain directory layout for source, binaries, tests, library files and so forth. This arrangement can be overridden, but doing so flies in the face of the convention over configuration mantram.

Fortunately, the project layout is eminently sensible, so migrating to it is not likely to be a problem, only a one-time hassle.

A complaint I have heard a few times is that there is not much in the way of documentation for Maven 2, so newbies have to work in the dark.

Fortunately, this is a misperception. There’s a lot of excellent documentation, but it’s not obvious where to find it. There are two comprehensive guides available at no cost in PDF format: ”Better Builds with Maven,” by four authors (www.devzuz.com/web/guest/products/resources), and “Maven, The Definitive Guide,” by three authors (www.sonatype.com/book). Both books run to nearly 300 pages and are excellent.

For those who want to enter the pool from the shallow end, Sing Li’s “Introduction to Apache Maven 2” (www-128.ibm.com/developerworks/edu/j-dw-java-mavenv2.html) is a great place to start and, at 35 readable pages, it gives you a quick, easy overview of the tool and how to get rolling.

In all these texts, you should avoid reading about Maven 1, which was a rather different beast in key ways.

Stick with Maven 2: Your days of cursing at Ant will be over, and your builds will be much easier.

Andrew Binstock is the principal analyst at Pacific Data Works. Read his blog at binstock.blogspot.com.


Share this link: http://www.sdtimes.com/link/31223
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading