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 mvnrepository.com. 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!
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 #
Posted by Erik Hatcher on April 16, 2007 at 07:23 PM MDT #
Posted by Soren on April 16, 2007 at 11:34 PM MDT #
Posted by Ben on April 17, 2007 at 06:09 AM MDT #
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 #
Posted by Benoit Guerout on April 17, 2007 at 06:19 AM MDT #
Posted by Benoit Guerout on April 17, 2007 at 06:24 AM MDT #
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 #
Posted by Robert on April 17, 2007 at 08:10 AM MDT #
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 #
- Ivy's repositories are pretty sparse.
- To find some of the dependencies you need, you'll need to point Ivy at Maven repositories
- 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: http://maven.apache.org/articles.html.
Posted by Rob Ottaway on April 17, 2007 at 10:56 PM MDT #
Posted by ejboy on April 18, 2007 at 07:53 AM MDT #
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 #
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 #
Posted by declan on December 04, 2007 at 08:52 AM MST #
* Managed jar files and package dependency
* Eclipse integration
* Run all unit tests
* Build jar files
* Generate my project website: http://www.shapelogic.org
The documentation for Maven is pretty spotty, but Eric Redmond has a great online book: http://propellors.net/maven/book, that helped me a lot.
Posted by Sami Badawi on March 28, 2008 at 08:47 AM MDT #
Posted by Tim O'Brien on October 13, 2009 at 02:39 PM MDT #
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 #
@Lorenzo
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.
Ivan
Posted by Ivan on June 25, 2010 at 10:49 AM MDT #
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 #