Matt Raible has been building web applications for most of his adult life. He started tinkering with the web before Netscape 1.0 was even released. For the last 16 years, Matt has helped companies adopt open source technologies (Spring, Hibernate, Apache, Struts, Tapestry, Grails) and use them effectively. Matt has been a speaker at many conferences worldwide, including Devoxx, Jfokus, ÜberConf, No Fluff Just Stuff, and a host of others. Matt is a DZone MVB and is not an employee of DZone and has posted 148 posts at DZone. You can read more from them at their website. View Full User Profile

Building a Better Maven with Ant

02.11.2008
| 8493 views |
  • submit to reddit

It looks like the Ant folks are thinking of building a better Maven.

I see many developers adopt Maven because they want a build system able to provide common features with no effort. Most of them don't want to spend much time writing an Ant script, or have seen or heard that maintaining Ant build scripts is troublesome. So they choose to use Maven only because it's easy to use for common use cases: install, write a simple pom of a few lines or generate it using an archetype, and you're ready to compile, test and package your new project following the Maven standard structure. They also get dependency management for free, and with only a few more effort they have multi module builds, and some nice features like code analysis, coverage, and a set of report gathered in a web site. That's really nice and that's what I like about Maven.

But Maven suffers from a lack of flexibility and robustness IMHO. And later the same people who first adopted Maven because of its perceived ease of use become frustrated when they need to tweek the system to their own needs or don't understand how the release plugin work. Then some of them go back to Ant, first having to go through a sometimes painful road to describe their whole build system in xml, especially if they aren't Ant experts. Others try to use new build tools like raven, buildr or others.

I really like Ant, and think it is a very good basis for robust and flexible build systems. People with enough knowledge of Ant can write very good build systems, testable, maintainable and adaptable. But you need to get your hands dirty, and you need to get a good knowledge of some of the mechanisms which can make an Ant based build system manageable: import, scripts and scriptdef, macrodef, presetdef, and so on. [Read More]

What do you think - is this a good idea?

I agree that Maven has its warts, but I don't think it's that bad. I've also heard that Maven has been successfully implemented at large companyies like eBay, Intuit and E*Trade[1]. Is the "Maven sucks" meme largely something that exists in the blogosphere, but not in the real world?

I think the biggest benefit of Maven is dependency management. I think it makes your code more modular and easier to build. Rather than having a monolithic source-code tree that depends on itself being built in a certain order, you can have individual modules that pull dependencies from a central location. This can be done with Maven's Ant Tasks as well. I don't see a problem with building a better Maven with Ant, but to try and build a better Central Repository sounds like a nightmare to me. The current repository has been improved for years and is much better than it was a couple years ago. That being said, I would love to see somebody build a more accurate Central Repository. Ideally, it'd be done sometime next week. ;-)

Speaking of Maven, there's an interesting comment on a previous post I wrote:

With all the critical remarks the Maven project is receiving, wouldn't it be time for some Maven project lead to step up and explain the team's position? Or is it completely deaf to the sentiments? How many builds have to fail, how much more headaches are needed before others start their own version of Maven and do it the right way (like Don [Brown])?

Seems like an excellent question to me. Guys?

[1] I could be wrong about these companies. If you're a developer at one of these companies, please confirm or deny. Any comments on Maven's success at these companies would be great as well.

References
Published at DZone with permission of Matt Raible, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Aidos Morg replied on Mon, 2008/02/11 - 8:56pm

I find the Maven vs. Ant debate is a little unfair, I think a fairer comparison to make is the Maven vs. Ant + Ivy.

Ivy (http://ant.apache.org/ivy/) is a dependency management tool that is designed to interact with ant which we've had quite a lot of sucess working with. Our major issue is with using Maven on existing codebases and on codebases that contain Java and native code. Personally if I was starting a new project from scratch which was entirely Java then Maven would meet my needs perfectly, if not then the Ant + Ivy combination gives you something close, yet a lot more flexible.

Matt Raible replied on Tue, 2008/02/12 - 12:24am

Did you read the mailing list post? I believe it's from the lead developer of Ivy. ;-) I agree that Ivy is a very nice solution for folks that really like Ant. I'm not sure if it's a better solution than Maven's Ant Tasks - but that's only because I haven't tried it personally.

Steven Devijver replied on Tue, 2008/02/12 - 3:08am

Hey Matt,

I can assure you that "Maven sucks" exists in the real world. As the Don Brown interview indicated, as I have repeated on numerous occasions and as other people continuously repeat Maven 2 makes its users loose time.

What's hard about big Ant files is the chore of setting up and maintaining them. Understanding the individual Ant tasks is not very hard, most if not all of them have decent documentation.

I've used the kind of common Ant files that Xavier proposes, they included Ivy support. The problems they caused for me is similar to my Maven 2 experience: when some unexpected error occurs, I may have to understand the internals of the black box I'm using in order to figure out the cause of my error.

This is a waste of time when it happens often. The effort required is frustrating because I'm unsure whether or not the complex abstraction is the cause of my error. The effort is not rewarding since often the complex abstraction makes it harder to understand the cause of certain errors.

A common set of Ant files and Maven's plugin system both enforces such a complex abstraction on their users. I believe that build systems need to have these layers of complex abstraction. The only way to avoid frustration and waste of time with your users as much as possible is then to:

  1. Design, design, get feedback, re-iterate, design, design, keep on designing, ... until your users are happy. The Maven brotherhood is doing some of this but far too little. Being religious about your design decisions does not help your users at all.
  2. Focus on your users, a lot. If your users are complaining, listen to them. Try to understand their complaints and try to help them. Again, the Maven brotherhood comes across as a religious sect that thinks it is right and nagging users are wrong.

In my experience Xavier has a history of listening to his users and helping them so I'm looking forward to study the design of his proposal. The big problem for me is the Maven culture where a few people are deemed to have the right opinions and everybody else is wrong or "doesn't get Maven". Maven sucks because they get some things right yet using Maven hurts and there's no medicine.

Steven

Fabrizio Giudici replied on Tue, 2008/02/12 - 6:08am

Well, today is another bad (health) day, so maybe I'm not understanding anything of the discussion, but let's try... First, I'm in the bunch of Maven haters. Not only I'm worried by the bad experience of people about lack of flexibility and reilability, but above all I see it as an unnecessary raise of the complexity. I'm not worried about writing some ant task here and there, and I prefer by far a simpler tool like ant. Most of all, I just can't understand the usefulness of the dependency stuff. When you create a new project, you define the set of dependencies, you download the jars and commit them in the repository. That's all. Everybody who checks out the project will get the jar files together with it - and they get VERSIONED (do you have this feature with Maven?). You'll have to upgrade the jar files once in a while, but - heck - just once in a while. So, somebody could please explain me which is the real advantage of having an automated system for dependencies, other than a fancy toy? :-) Furthermore, some customers I have really don't like the idea of depending on a Maven repository - they WANT to have all that they depend on committed in their own repository, for being sure of having the control of everything. Frankly speaking, I can't blame them.

 

--

Fabrizio Giudici

Moritz replied on Tue, 2008/02/12 - 8:21am

"Building a better Maven with Ant"? Do you guys know the history of Maven? Maven was once a layer on top of Ant (say: "a better Ant" ;-) ). After the developers discovered, that Ant is not flexible enough, they created their own stack.

 Maven is not just for dependency management. Its strengths lie in a comprehensive project structure and plugins, that make project management easy. With maven, you only set up a project descriptor. With Ant you have to create all the steps for yourself. With a working project descriptor, Maven can execute many reports and tools, such as building a website, creating documentation, running tests, publishing files etc. With Ant you have to do it all by yourself. Want some more? With a project descriptor, you can create IDE specific project files on the fly. You work with Netbeans, but your co-worker works with Eclipse? No problem.

 @Fabrizio: Maven works with two types of repositories: remote repositories and local repositories. All jar files are stored locally and you can run builds offline without a problem - unless some jars are missing. You can create your own remote repository with files that are missing. You can configure as many remote repositories as you like, not just the central Codehaus repository, but there are many more. Versioning jars has been introduced by Maven. The file name convention <group>-<name>-<version>.jar ("commons-lang-3.1.jar") has been established through the Maven repositories. You can distinguish between stable jars and development snapshots, which will change frequently. Maven supports deployment of development snapshots to remote repositories.

 

Steven Devijver replied on Tue, 2008/02/12 - 9:11am in response to: Moritz

"Building a better Maven with Ant"? Do you guys know the history of Maven? Maven was once a layer on top of Ant (say: "a better Ant" ;-) ). After the developers discovered, that Ant is not flexible enough, they created their own stack.

If this is true they made a huge mistake. One word: AntBuilder.

Maven is not just for dependency management. Its strengths lie in a comprehensive project structure and plugins, that make project management easy. With maven, you only set up a project descriptor. With Ant you have to create all the steps for yourself. With a working project descriptor, Maven can execute many reports and tools, such as building a website, creating documentation, running tests, publishing files etc. With Ant you have to do it all by yourself. Want some more? With a project descriptor, you can create IDE specific project files on the fly. You work with Netbeans, but your co-worker works with Eclipse? No problem.

Great ideas, unfortunately not very well implemented. These ideas are not unique to Maven. A Maven killer could easily provide them while at the same time make users happy, like Maven should do.

David Heffelfinger replied on Tue, 2008/02/12 - 9:42am

I personally like Maven. I like that it strongly encourages a uniform project structure. This makes it easy to navigate most projects using Maven as a build tool, if the project follows standard Maven conventions, you know where the Java source is, where the JSPs are, where the property files are, etc. With ANT, every project is different, since there is no standard project structure.

Regarding dependency management, where it shines is when you have two dependencies that in turn have a common dependency, for example, Struts and JasperReports both depend on commons-digester. If a project depends both on JasperReports and Struts, Maven will detect the common dependency and download a single copy of the jar file, to be shared by both Struts and JasperReports. If we were to get each dependency by hand, and get all of their dependencies from their respective web sites, we could potentially get multiple copies of a single dependency if we are not careful. Maven frees us from having to look out for this kind of situation.

 

 

Hans Dockter replied on Tue, 2008/02/12 - 11:42am in response to: Matt Raible

Hi Matt,

I have been long term Maven user who has recently switched to Ivy. IMO Ivy plays in a different league than Mavens dependency management. Ivy is so much more powerful and flexible than Maven. It is even more powerful than Maven when accessing Maven repositories. And Ivy provides not just a set of Ant tasks but also a deep API which allows for deep integration with third party tools.

There is one problem with Ivy. Its power and flexibility, which means also its complexity, is slightly overwhelming. I think what is missing for Ivy, is a layer on top of Ivy, which preconfigures it and integrates Ivy in a build-by-convention approach. I guess this is what EasyAnt is about. I think in general XML based build systems might have passed its climax. But as Ivy allows integration into any tool, some other alternatives might be available soon.

Florian Kammermann replied on Tue, 2008/02/12 - 11:54am

Ok first I'm a maven-lover. Our deployment is normal ear-application with war's and ejb's (xdoclet-generation). Before maven we had 4-6 hours to install a new workplace with all dependencies and environment-variables. After introducing maven it decreased to 10 minutes (checkout the main-source-tree, run the install in the main-pom, then in the project-pom and you have your ear ready to deploy) I had my headaches to (eg. with the xdoclet-plugin and the test-plugin which didn't run testsuites). But over all maven saves me much time with all the features moritz listed. I find one off the biggest advantages of maven, that it supports you very well in moduling your applications, what have a great impact in the reusability of your code.

Fabrizio Giudici replied on Tue, 2008/02/12 - 12:11pm

@Moritz: ciao! :-)

@Florian: can you please tell me what would be the problem with just checking out your project from a repository for setting up a new workplace? Clearly there's some complexity in your project that I can't understand.

--Fabrizio Giudici

Michael Parmeley replied on Tue, 2008/02/12 - 2:09pm

I have messed with Maven slightly and have never seen a reason to switch from ANT. As far as depenency management I find this an odd requirement because everything needed to build the project should be in version control.

Check out the project, run "ant all", done. If you have a whole bunch of setup to do to build a project after you check out the project you are doing it wrong. (For Web App projects my build files require one environment variable to be setup that points to a J2EE implementation)

Now, a reason I don't like Maven. We are trying to extend Hudson (https://hudson.dev.java.net/) it uses Maven as its build system. We are unable to get it to build because our company apparently as a lot of the Maven repository URL's blocked. I really have no way of knowing (and this could because of my ignorance of Maven) which sites are blocked so I can't even figure out which sites to request to be unblocked. A teammate of mine built it at home and it took an hour for it to download everything and build.  This seems unncessary. All dependencies should just be in version control, not having them there seems like a bad idea.

 

 

Ignacio Coloma replied on Tue, 2008/02/12 - 3:19pm

Maven has a good dependencies repository. That's the main (sometimes only) reason people keep using it. The rest of the ideas are questionable (crappy websites coming from default maven installs) and the implementation is just plain bad.

There is no chance of creating a competing repository, as the ivy guys learned some time ago. I like the ivy dependency system (it's quite superior to maven), but it should have been planned as a pom.xml embrace-and-extend instead of a from-the-ground-up effort. Currently, ivy users must understand ivy.xml AND pom.xml when something fails.

I always recall the same example: if you are a simple framework with several dependencies, maven will do fine. But ivy offers reasonable solutions for the spring framework that maven does not, and that has driven them to their current pom-hell.

Dimo Velev replied on Tue, 2008/02/12 - 3:55pm in response to: Fabrizio Giudici

Hi Fabrizio,

The problem with writing ant tasks here and there is that you often end up writing the same tasks for each project you have - you always have some kind of clean, compile, run unit tests, generate documentation (javadocs, etc) and packaging.It really gets boring writing the same things over and over again and whats worse - you will have to modify a lot of build files in case you want to change e.g. the documentation generation task.

Sure, you can checkin some jars into your version control system. You commit something that is never really going to change (well, it might only get deleted and incidentally a new version of the same thing under new name would usually be added at the same time). Aside from the longer checkout and the size of the version control repository, that is not a big problem. What about dependencies among your own projects which change a lot. Lets say you have two projects - a utility jar and another one. You collegues work on the utility jar and you work on the rest. How do you synchronize? Do you always build both projects and copy the dependencies from the one to the other? Do you copy the jar-s to a central location? Maven helps a lot in that. Of course maven versions the built artefacts...

Another nice feature is the ability to deploy source code and javadocs to the maven repository. Having a reasonable maven support in your IDE allows you to debug through the code of your dependencies without having to open them as projects or point the IDE to the source code location. It works the same with javadocs.

Yes, most customers want their own repositories. Nobody really relies completely on the central repository. You can install your own repository, set rights (who can deploy/read what) and configure maven to use this repository. You can configure your own maven repository to either work as a caching proxy of the central repository or just rely on the artefacts you personally deploy. You have all the control you want. Maven repositories like artifactory also come with a smooth web GUI :).

Hope that helps you understand some of those maven users like me that you see from time to time :)

Regards,

Dimo

 

Russel Winder replied on Wed, 2008/02/13 - 11:14am in response to: Steven Devijver

Using Groovy and AntBuilder is great but there is a lot of infrastructure that everyone will replicate. Enter Gant (http://gant.codehaus.org). The whole point of Gant is to allow build specifications to be written in Groovy using the AntBuilder but with all the core boilerplate code already done for you.

I like Maven though, well for projects that fit the Maven model anyway. So Gant has the Maven target set. I have a project for which the Gant script is:

includeTargets ** gant.targets.Maven * [
groupId : 'org.devjavasoft' ,
artifactId : 'ads' ,
version : '3.1.0' ,
javaCompileProperties : [ source : '1.6' , target : '1.6' , debug : 'true' ] ,
testFramework : 'testng'
]

cleanPattern << '**/*~'

setDefaultTarget ( test )

I like Ant and the Ant tasks as well, especially where flexibility is required, but I hate writing specifications in XML, especially when the build algorithm cannot be specified as a purely functional program. So Gant is ideal for me in this context; it uses all the Ant tasks (include the Maven Ant Task and the Ivy Ant task) but scripted using a dynamic language, Groovy.

Tony Nys replied on Thu, 2008/02/14 - 4:38am

Hi all, and Steven,

 

Me too, I fell in love with Maven 2, withs it's project model and transitive dependency management.

In all projects in the last 2 years, I've been using maven.

Of course there are allways other tools and more flexible tools. Create a small script here, copy a file there...

With maven, you're not so flexible; which is not a bad thing only; it forces you at least to think about what you need.

Doing lots' of integration work with developers, especially junior developers need to be "forced" into a system, structure if you like. They don't have the time nor the overall knowledge of the complete build system. They need to be shielded from this.We tell these developers basically two things: "mvn eclipse:eclipse"  and "mvn clean install -P dev". In this way they have their depencies/versions aligned, and they can do a build. They don't need to know more.

 

Of course MAven  does not cover everything, but hey, there are plugins, the basis of maven itself. Even yesterday I ran into a maven problem, I want to do inheritance of properties defined in profiles inside a parent pom structure. I extended the process-resources plugin for this...

 

What I still miss is a tool on top of maven which really allows you to GUI-wise (eclipse) to do release management, branching, ... => all in one. I know there's the tools from Convergence ?

In the M$ world, there's now the TeamServer, having the all-in-one package. 

 

 Tony

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.