Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta.

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.

RE: Why Grails doesn't use Maven

Graeme Rocher's in Why Grails doesn't use Maven:

In his post entitled "Grails - The Good, The Bad and the Ugly", Jonas has some nice praise for Grails, his main beef is that it is not built on Maven.

So I wanted to clarify why exactly we chose not use Maven (by default) and the explanation is there for all to see in Jonas' first example of creating a Grails application vs creating a Maven project:

Instead of

grails create-app name

could be just

mvn archetype:create -U\
-DgroupId=your.proj.gid -DartifactId=your-proj-id

My goodness, what a mouthful the Maven example is. There is a common acronym in the open source world called RTFM (read the *ing manual), when a user asks a question on a mailing list and the "experts" respond by pointing them to the place in the manual.

I think Maven's biggest problems are 1) poor metadata in the central repository and 2) the source of metadata in projects (pom.xml).

I believe #1 can be fixed if the Maven guys allow dependencies to be fixed based on user feedback. It's also gotten a lot better in recent years. In reality, maintaining transitive dependencies is hard and I believe Maven has done a good job. In reality, they're the only ones that slurp up transitive dependencies, so the only other option is to maintain the dependencies yourself.

To fix #2, I think the problem is mainly XML and the verboseness of the elements-only pom.xml that Maven requires. Most of the contents of a pom.xml are either dependencies, plugins or exclusions/variances of Maven's conventions. What if Maven's metadata was pluggable? What if XML was only one option? What if you could write a pom.groovy and describe your entire build process in 5 lines instead of 500? That would be very cool.

I'm still a Maven fan, mostly because it's greatly simplified the maintenance of and releasing of AppFuse. When I do GWT, Seam or Grails development in the future, you can be sure I'll try to use Maven to do the development. Why? Because I've learned how to use it and I don't feel the pain that so many others talk about. I also think it really shines on really large projects (builds that produce 30+ WARs for example). An Ant-based system on really large projects can become quite burdensome and difficult to maintain. Not only that, but it's very difficult to maintain a modular build system (where you can build/test/deploy a single WAR) with Ant. In my experience, really large Ant-based systems take forever to process that everything is up-to-date whereas Maven systems depend on each other and require you to keep them up to date. Sure it requires you to be smarter and run "mvn install" on your subprojects, but I'd rather do that than wait 5 minutes for Ant to process everything just to run a test.

You might remember that the main reason I used to prefer Ant over Maven was speed. That was in Maven 1 days. With Maven 2, speed is no longer a problem and I've found it much easier to run "mvn jetty:run" than "ant deploy" and wait for Tomcat to restart. IMO, the perfect development environment is one were you can run a command-line command (or use your IDE to start the server) and code away without worrying about restarts. Seam and Grails offer this environment, but it's unlikely your entire organization is going to use standardize on those frameworks and not have anything else. I think Maven and the Maven Jetty Plugin offer a nice alternative for the rest of those applications.

Posted in Java at Jan 16 2008, 10:49:35 AM MST 11 Comments

Excellent points and I agree with you 100%. Our team use to use ant and the build files were enormously HUGE. Maven 1 was a massive improvement for our situation and maven2 has improved it as well. Great article.

Posted by James Lorenzen on January 16, 2008 at 10:14 PM MST #

Any GNU/Linux packaging system I've used can handle transitive dependencies just fine, even for Java libs/apps. It's old tech. I am continuously amazed why it's such a big deal in the Java world, year after year. Just apt-get it.

Posted by Dalibor Topic on January 16, 2008 at 10:48 PM MST #

I have to defend Ant. Tonight, I attended my local Spring User Group meeting and the speaker did an awesome job covering how he designed and developed the Wikia search engine and it's social network app (open-sourced as Foowi). It's a big Spring MVC/ iBatis app that was developed in Eclipse and built with Maven. It was very interesting to hear how he used Eclipse, Ant, and Tomcat to do rapid edit, compile, deploy cycles. This was all handled from within Eclipse, withOUT tomcat restarts.

Spring meeting on Wikia Search/ Foowi

Posted by erik weibust on January 17, 2008 at 12:15 AM MST #

Ivy also handles transitive dependencies. We use it, and it works really well. The only issue I've seen is with IvyDE - the Eclipse plugin. We often have tell it to re-resolve the dependencies of a given project.

Posted by Mike Dunbar on January 17, 2008 at 06:24 AM MST #

Maven is the only one to do transitive dependencies? Maven barely even does them, and certainly not as cleanly and flexibly as Ivy. Maven is a boatload of baggage that keeps you from getting things done, but people put up with it because they don't know that better tools exist.

Posted by Jason Carreira on January 17, 2008 at 09:51 AM MST #

James, if your Ant files were huge, you weren't using the import features of Ant correctly to reuse a common build template. It's relatively easy to make your module build files around 3 lines long (if they don't need anything different) and still have the flexibility to customize your build that you sign away when you start using Maven.

Posted by Jason Carreira on January 17, 2008 at 09:53 AM MST #

I think the major difference between Ant and Maven is who's to blame for a shitty build process. With Ant, if the build process sucks, it's likely your fault because you have full-control over how everything is done (imports, update-to-date checks). With Maven, you don't have as much control therefore Maven gets blamed for your poor build process (appropriately so). I don't think anyone thinks that Maven is a bad idea - it's just a poor implementation of a good idea.

Painful build process with Ant = Your Fault.
Painful build process with Maven = Maven's Fault.

There's definitely a lot of room for improvement in the "build tools" space. However, since most of the build tools are free - there's probably not a whole lot of inspiration for companies dumping money into making something better.

Posted by Matt Raible on January 17, 2008 at 12:14 PM MST #

@Jason Carreira.

Maven is the only one to do transitive dependencies? Maven barely even does them, and certainly not as cleanly and flexibly as Ivy.

Here's the kicker about Ivy. There are almost no libraries available in Ivy repositories, so you have to point Ivy to Maven repos. Ivy 1.x does not handle transitive dependencies of Maven repos at all. Ivy 2 (in beta) does, but in the end Ivy's success is going to be beholden to all the work that's gone into Maven.

Maven is a boatload of baggage that keeps you from getting things done, but people put up with it because they don't know that better tools exist.

Really? That's guite a trollish statement. From my experience, Maven is an incredible tool that greatly simplifies development of projects. If I need to step outside of Maven's capabilities, I usually have the Maven build call an Ant file to do custom work although there's no reason it couldn't just as well execute a buildr or gant script.

Posted by hohonuuli on January 17, 2008 at 01:23 PM MST #

p.s. I just want to mention that you don't have to exclusively build with Ant or Maven. They can take advantage of each other to use their respective strengths.

For example, you can use Ant for your build and have Ant use Maven (instead of Ivy) to manage the dependencies. See for an example.

On the flip side you can build with Maven but use Ant for custom tasks. See and for an example.

Posted by hohonuuli on January 17, 2008 at 01:31 PM MST #

The first thing Maven needs to do is to drop the XML configuration.

It is amazing to scroll through a pom.xml file in a very fast manner, there are so many indented lines, it is like watching a ASCII movie.

Posted by Sakuraba on January 18, 2008 at 03:21 AM MST #

Good post Matt!

Every day I curse Maven. Every day I praise Maven. I hate it and love it all of the time.

I remember although it could be better it is a far cry from using Ant.

Since I travel a lot and consult/develop a lot.... I have seen so many snarly Ant build scripts. At least with maven, I have to just tame one beast and one philosphy. With Ant, it is random beast with many heads.

A while back, I created some code gen bits for Presto using Maven 2 plugins (written in Java). I am thinking about creating some code gen bits for Crank. I am leaning towards Groovy + Groovy CLI using IntelliJs Groovy support for some of the same reasons as above.

Posted by Rick Hightower on January 19, 2008 at 02:41 AM MST #

Post a Comment:
  • HTML Syntax: Allowed