Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

Ant vs. Maven

I found a good post from Steve Loughran on what's wrong with Maven's repositories. I agree with most of his points, but would like to point out This site seems to provide good XML Feeds for what's been uploaded to Maven's Central Repository. If you're using Maven, you should probably subscribe to its Atom Feed.

In related news, Timothy M. O'Brien has an entry about Steve's upcoming book: Ant in Action. This book is the 2nd edition of Java Development with Ant. I have a hard time believing Erik Hatcher is helping Steve write Ant in Action - AFAIK, he's off in Rails-land enjoying himself. Regardless, I'm sure Ant in Action will be an excellent book. Java Development with Ant is one of my favorite technical books of all time and is largely responsible for inspiring me to write AppFuse. I read JDwA way back in October 2002 and used a lot of its code to develop AppFuse 1.x's Ant-based build system.

Like Tim, I still like Ant. However, AppFuse 2.x uses Maven 2 and most of the projects I work on these days use Maven 2. It may surprise some folks, but I actually like Maven 2 (not Maven 1). Sure it has issues, but after a year of using it in anger, I know how to solve most of its quirks. AppFuse 2.x users will benefit from this greatly and I'm thinking of changing its tagline to "We make Maven work." ;-)

One of the most interesting things about moving to Maven is we were easily able to make AppFuse more like a framework than a project starter kit. We thought this is what most folks wanted - especially the ability to upgrade a project to the latest version of AppFuse. While some folks wanted this, it seems like most folks liked the full-source version that was a pain-in-the-ass to upgrade. I don't blame them. On the project I'm on, I'll likely be converting to a full-source version before the project is over. That's why APF-675 exists. I doubt we'll make it happen for the 2.0 final release, but it is on our radar of things to do shortly after. With any luck, we'll create a way to migrate projects using embedded AppFuse to full-source AppFuse.

I'd also like to point out something ironic. With AppFuse 1.x, there were a lot of folks that advocated we move to Maven. Their primary reasoning - the Ant build scripts were too long and complicated. How about a good ol' lines of XML comparison for those folks:

  • Lines of Ant-related XML in AppFuse 1.x: 1655
  • Lines of Maven-related XML in AppFuse 2.x: 2847

Oh wait, that's not a fair comparison. The above number is for AppFuse in SVN, which end users won't deal with. A new project created with AppFuse 2.x will likely have a pom.xml with 634 lines. That's about 1/3 of the amount needed for Ant in AppFuse 1.x. Maven hasn't exactly gotten us away from XML hell though. How about a LOC count for archetypes vs. installers:

  • Lines of Ant-related XML for AppFuse 1.x framework installers: 2786
  • Lines of Maven-related XML for AppFuse 2.x archetypes (including archetype's pom.xml files): Too much to count. Creating archetypes is waayyyy too complicated IMO. Basic archetypes seem to be around 740 lines (pom.xml for archetype project, archetype.xml and archetype's pom.xml), modular archetypes are around 870. 740 x 4 + 870 x 4 = 6440. I'm guessing the full-source archetypes will add another 5000 lines of XML. Ugh.

This XML-for-archetypes comparison might be unfair as well. With 1.x, you could only create a webapp, with 2.x, you can create a modular application and chop off the web-portion if you so choose.

Of course, the real benefits of moving to Maven are elsewhere. We've seen quite an uptick on the mailing list in the last few months. There's tools cropping up and I've gotten quite a few inquiries about training (yes, I do have a 3-day course on Spring, Hibernate, Ajax, Maven and AppFuse). To me, AppFuse 2.x seems more complicated than 1.x, but it seems the community thinks otherwise. Judging from the increased amount of developer activity on the project, developers seem more interested in a Maven-based system too. Then again, we are making Maven work!

Posted in Java at Apr 16 2007, 11:26:13 AM MDT 25 Comments

In my opinion, maven2 is a huge roadblock to any developer not using maven who wants to get involved with the project. My heart sinks every time I go to download source and I see that now-too-familar maven2 overly engineered project structure. I'm watching as all of the developers who have blogs I read post their "We're switching to maven2!", "Has anyone seen this problem with maven2 yet?!?", "Here's what I hate about maven", and finally "You should totally switch to maven2" posts.

Unfortunately, this reminds me too much of the Friendster -> Orkut -> LinkedIn -> MySpace -> Whatever grind where your friends are trying to sell you on the hot new something they've already committed to. Maven2 is a social app that benefits from other developers doing it too (incidentally this makes me discount any recommendation for it that I read). The only difference is that there's a new social friend site every week and a new build system only gets traction every few years. I think this is what makes it tragic... we're all jumping from a flawed build system to one that is a different flavor of flawed.

Maybe they way you use it makes the things I dislike go away. (I haven't needed to work with appfuse source yet) But I think you need to balance your view of the uptick of interest in your project with the natural growth your project would have seen anyway and the people who are turned off by it because of maven2. I don't know... maybe I'm being a curmudgeon and I just need to suck it up and learn it. But for me, reading up on it makes me feel like it's a system trying to beat me into submission. It feels like EJB2, or old school JSP/Struts. I dislike ant with a passion but I still think that doesn't mean maven2 is the right solution to the dependency resolution/building software problem.

Posted by Paul on April 16, 2007 at 06:37 PM MDT #

Matt - I've been discovered! My ghost writer is in fact Steve's alter ego. Steve single-handedly tackled the 2nd edition of JDwA (renamed to Ant in Action). It's true that I'm doing lots of Ruby (even on Rails) these days and enjoying it, but I'm also doing tons of Java as well as it relates to Lucene and Solr. I don't tinker with Ant much other than as a user of the build systems of those projects, but I do type "ant" several times a day :)

Posted by Erik Hatcher on April 16, 2007 at 07:23 PM MDT #

I agree with Paul that Maven2 is the "new thing" that everyone is jumping to now. However, I don't agree that its for the sake of switching. Everything has a learning-phase, and Maven2 has one aswell. It takes time before you get used to your new tools, and during that time you are almost for sure about to scrap the tool and go back to what you did before. It was the same thing when ant came out and everyone had to learn it instead of their Makefile tools. The important is that like Matt, people make it work.

Posted by Soren on April 16, 2007 at 11:34 PM MDT #

And what about Ant + Ivy ?

Posted by Ben on April 17, 2007 at 06:09 AM MDT #

I think Ant + Ivy is a good solution, but I've been using Ant + Maven 2's Ant Tasks with quite a bit of success. The thing I like about Ant + Maven 2's Ant Tasks is I can offer support for both Ant and Maven in the same project. AppFuse Light (formerly Equinox) does this.

One of my favorite things about Maven 2 is its very easy to checkout a project, run "mvn idea:idea" and start developing/testing it in my IDE. Good luck doing that with an Ant-based project - unless the project files are checked into source control.

Posted by Matt Raible on April 17, 2007 at 06:17 AM MDT #

Ivy provides a great dependencies management and publishing capabilities. Moreover, it can be easily coupled with Ant

Posted by Benoit Guerout on April 17, 2007 at 06:19 AM MDT #

I should spend some time on Maven 2 + Ant to be able to compare this one with Ivy. I May be I should have a look at AppFuse 2 and how you have coupled Maven 2 and Ant.

Posted by Benoit Guerout on April 17, 2007 at 06:24 AM MDT #

Benoit - AppFuse 2 doesn't offer an Ant option yet, but we plan to. You could look at AppFuse Light's build.xml and pom.xml for how we allow Maven or Ant. If Ivy allowed specifying dependencies in pom.xml, I would certainly be more interested in it.

One thing that Maven has given us on AppFuse is a very modular project - now the lines between packages are much more clearly defined and it's much easier to do things with it because of its modularity. With 1.x, you were stuck with Ant. With 2.x, it'll be possible to use Ant, Maven or even Ant + Ivy/Ant + Maven's Ant Tasks. At this point, the reason we haven't created a full-source, Ant-based archetype is merely because of time constraints.

Posted by Matt Raible on April 17, 2007 at 06:33 AM MDT #

Ant + Maven's Ant tasks has always struck me as a "worst of both worlds" combination. You get the limited dependency management available with Maven (as opposed to the more flexible DM given by Ivy), and when it comes time to set up your IDE, you don't know your correct classpath, as all you have is a bunch of JARs sitting in your .m2/repository.

Posted by Robert on April 17, 2007 at 08:10 AM MDT #

There is only one thing worse than Maven, and that is working without it. And that is saying something, because Maven can be a complete PITA.

To enumerate alll the problems I have had with Maven would be a waste of time, but they are in the dozens and dozens of hours. Which is why I have the "bail early and bail often" rule in Maven. When something doesn't work I try to remember to give up immediately and use "ant within a Maven" script so I can go about my business.

The bottom line for me is that all the heartache and pain is worth it. I am constantly moving from new project to new project, and without Maven there is no standard for anything. With Maven it is all getting standardized, easy, dumb, and most importantly I am focusing on the work and not the infrastructure.

SOA is now not just a buzz word, because I make nice small dumb projects that do one thing well, and without a whole lot of effort, using Maven archetypes.

Maven solves most of it's own problems relatively quickly, but then new ones crop up because once people spot a standard, they bolt new things onto it that would not be thinkable if things were not standardized. So I expect and relish many years of new problems to come. Yuck. So goes life.

Posted by Pete Carapetyan on April 17, 2007 at 09:25 AM MDT #

I dont think people are switching to maven2 just for the sake of switching... I think it's a combination of frustration with ant, knowing that there's got to be a way of doing it, and the vocal support of maven2 from peers which (in the lack of alternatives) therefore sounds like the way to go.

The vocalness of people using maven2 is an artifact of the fact that it really plays much nicer with other projects that use maven2. This encourages users to promote it more than a more simple project that works around the way you structure your project.

The issue I take with maven2 is that it is opinionated about how a project should be structured and I don't really like it's opinion, doesn't really remove any of the xml annoyances of ant, seems brittle and has a high barrier of entry both for learning and converting projects. I haven't really found the solution to the problem, I just have a feeling that maven2 isn't it and I'm resisting, hoping that I can make ant work just a little bit longer until I find the real answer.

Posted by Paul on April 17, 2007 at 10:37 AM MDT #

I like Ant. I like Ivy. I like Maven2. They are all good tools and have their place. For those who are thinking about trying Ivy . A few things to keep in mind are:
  1. Ivy's repositories are pretty sparse.
  2. To find some of the dependencies you need, you'll need to point Ivy at Maven repositories
  3. Ivy does not handle transitive dependencies for Maven repositories very well.
Personally, I've been using Maven2 for most of my new projects and have been pretty happy with it. For projects where Maven doesn't quite work I've been using Ant + Maven2 Ant Tasks (<- for dependency management)

Posted by Hohonuuli on April 17, 2007 at 10:38 AM MDT #

Maven and Ant might both build .jar files, but they are two very different tools. Maven I feel will put more control into a single administrator's hands. Using Ant has always been best (quick) for me when working solo, or with one other person.

With Maven many project details are hidden away from developers. To be specific artifact repositories, website generation, version of Java, continuous integration etc. This can be done by having projects inherit from a parent pom. With Ant everything is out in the open, or shall I say naked ;) This is not always bad either, just different.

Maven requires a large push to get up and running well, but I believe it works great for large projects. Maven's snapshot mechanism, coupled with other features, allow for speedy development (minus initial investment). Projects can be subdivided into small pieces, which are worked on by many developers.These pieces are in turn assembled into larger projects. An artifact snapshot can be released at any time, so that it is available to other projects/developers. Project artifacts can be reused over and over; again, with help from the dependency mechanism and pom inheritance. Maven will handle storing and fetching dependencies.

Just my 2 cents. BTW there is a pretty good book for Maven 2, and it is completely free. It is called "Better Builds with Maven", you can find it here:

Posted by Rob Ottaway on April 17, 2007 at 10:56 PM MDT #

Maven is not complex. You are just dumb ;) I think we need something like See SOA Facts as a reference.

Posted by ejboy on April 18, 2007 at 07:53 AM MDT #

As somebody already mentioned the problem with Maven2 often is maintenance and extensibility. Project startup using Maven2 is very quick - just set up and run. But later when you need more specific things you have to spend hours/days trying to find solution or create some workaround. Or, for example, O wanted to use maven-dependecy plugin which was officially published and documented. But. As Maven2 changed their plugin structure this plugin couldn't be reached in repository. I waited for it several months but didn't succeed (author in forums said that soon-soon they will 'enable; this plugin). In this situation you bacome very very angry on Maven2 as it becomes unusable.

It's strange also that maven guys don't know that xml attributes can be used - because of lack of them poms are becoming very huge.

I thing that Maven2 can be usefull for opensource projects or prototypes - when you want just to easily start using something. But in normal commercial project you will not start downloading jars every day, you will not be using default maven-style website. And when you start using continous integration tools (as luntbuild) you also have to pass various configuration parameters to maven.

BTW we just switched from Maven2 to ant+ivy having project with 11 modules. And now it's much more clear, runs quicker, less xml code, and is more safe.

Posted by Saulius on April 23, 2007 at 01:29 PM MDT #

I am trying to introduce the appfuse to our company but the biggest issue is maven. Most developers are familiar with ant and they think maven is not flexible enough. The administrators do not like the idea that everybody has to download jars from outside everytime to build.

I know it is sensitive topic about maven and ant, but I just want to express the reality here.

by the way, since you are working as consultant, how do you convince those companies to use maven instead of ant? I found it is very hard for commercial companies to adopt the maven.

Posted by Hank on October 25, 2007 at 01:03 PM MDT #

Hank - for anyone that uses Maven, I recommend they install something like Artifactory to store all their dependencies inside the firewall. Tools like this will auto-sync with external repositories and allow you to publish your own artifacts as well.

Posted by Matt Raible on November 01, 2007 at 11:10 PM MDT #

I'm looking at Maven. Some questions:

1. Why would I want to fetch binary jars from the Net? To get the "latest" version? Does this make sense in a nightly automated build environment? Seems pretty silly. Most of the time you can only upgrade a jar when no new bugs are introduced thereby.

2. Why would I want to keep my jars anywhere else but in the SVN repository? Why on earth would I want some Maven repository?

3. Why only earth would I want to code in Jelly? This one takes the cake. Jellly should be renamed "Crap".

I remember a few years ago I spent 2 weeks trying to build NetBeans from the Ant script, only to finally give up and simply throw all the source files into a directory. Result? Built it in < 30 minutes using Eclipse.

M'boys, the software world is full of crap.

Posted by Jonhhy on November 13, 2007 at 05:02 AM MST #

It has to be said that Maven 2 does have its problems coupled with a fairly steep learning curve. We have recently migrated to Maven 2 from Ant and it has proved to be quite unpopular and painful. It seems - like so many new technologies - people need to know its limitations. The documentation (Better Builds with Maven) makes some pretty spectacular claims. But it doesn't always deliver. We've also been using Artifactory, which has some associated problems of its own (adding the correct repositories etc.) which has added to the pain. I would recommend getting to grips with Maven without this for starters. Another pattern I've been seeing is that its being blamed for everything. In reality, it's not <em>always</em> Maven. We are now starting to see the benefits. SoA is much better defined and as a result the solutions are cleaner. All in all, I have faith in Maven 2. I also beleive that by using it, we're helping to make it better!

Posted by declan on December 04, 2007 at 08:52 AM MST #

I started using Maven 2 a year ago, after using Ant for years. I have a moderately sized open source project and Maven 2 did everything that I needed, with relatively little work:
* Managed jar files and package dependency
* Eclipse integration
* Run all unit tests
* Build jar files
* Generate my project website:
The documentation for Maven is pretty spotty, but Eric Redmond has a great online book:, that helped me a lot.

Posted by Sami Badawi on March 28, 2008 at 08:47 AM MDT #

Somehow, I ended up on this page from someone's recent Twitter activity. I still feel the same way about Maven vs. Ant. I think Maven is preferable (not surprised, right?), but if someone really wants to put up a good fight, I'll willing to go along with Ant (or whatever). What I'm now inflexible on is the idea of using a repository manager that conforms to the Maven standard. Developing software without a repository seems crazy to me, but I know that the vast majority of developers still haven't figured this out.

Posted by Tim O'Brien on October 13, 2009 at 02:39 PM MDT #

[Trackback] Raible Design: Ant vs. Maven Sonatype Blog: How to convert from Ant to Maven in 5 minutes...

Posted by paradox1x on February 24, 2010 at 11:45 PM MST #

For days now I have been suffering from messages about it being impossible to download missing artifacts. When looking in the repositories I see indeed that one or other moron has deleted in-between versions (e.g. codehaus-containers) a.o.

Maven has, so far, NEVER worked from the first time. I ALWAYS had to manually intervent to some point. Either some dependencies could not be downloaded or some stack trace about some property could not be read etc etc.

Maven is to my humble opinion written by people who may be nice home-garden-kitchen developers but who lack any insight and vision about the high level that we are trying to reach in developing enterprise software. That is, stable, reliable, easy to maintain software written following the rules of the art and which allow you to focus on the business development, NOT to spend days looking on Google for solutions to why the build tool does not work...

I realize I will piss many people off by saying this. You should know I have NO intenrion to hurt anyone personally or to start a flame or whatever. This is just my experience with it. True, with Ant one has to bother about more work before you get there but at least you get total control and it simply works. I believe Maven has a loooong way to go before it is reliable... The idea behind it is good though. And if ever it works by just a click with the mouse, it will definitely save a lot of time. Till then however it has been nothing but total agony for our entire team here and I'm speaking about senior developers, dudes with 15 or more years of experience in enterprise software develoment!

Posted by Lorenzo on May 05, 2010 at 05:45 AM MDT #


IMHO you are just right!

I can excuse maven developers only because the matter is not so simple as it can seems at a first glance.


Posted by Ivan on June 25, 2010 at 10:49 AM MDT #

The debate goes on.

In my own experience, building a huge Java App with Ant is like building things in dark. You throw in jars without knowing if you are really using different version(s) of jar(s) that have been a dependency by another jar(s) that you are really depend on. ONE SHOULD TRY TO FIGURE ALL THAT OUT BEFORE A JAR CAN BE PUT INTO THE WAR, RIGHT?

It's not a simple problem to solve by itself because the open source nature of the Java World. That might be the reason why there is no such a need in the .Net world? You buy from Micro Soft and then you are safe.

Due to the diversity of the Java open source community, as of now, i think none of the big enterprise can avoid 3rd party open source jars today. IBM, Oracle and Adobe are using them all over in their enterprise level products. The only way to protect ourselves is to figure out what are the exact versions of those dependency used in the application.

With maven and it's Eclipse plug-in, it's getting much clearer to figure out if there is a possible conflict. Also, that really encourages us not to check in jars into our SCM (SVN, CVS...) itself. Changing the version of 3rd party jars (or your own jars) become so much easier because the problem can be seen early on.

The initial learning curve may be steep. However, I think it's only because using Maven, you are not supposed to just blindly throw a jar into your build and hope for the best.

We have been using Maven + Nexus (for repo behind firewall) + Hudson (for build management and more) successfully. We have seen a huge ant build script that tries to combine all the artifacts without any pattern or discipline. Maven may not be perfect yet, but until a perfect tool comes out, we will keep using it and make it work better for us.

Posted by Jason on August 03, 2010 at 10:13 AM MDT #

Post a Comment:
  • HTML Syntax: Allowed