What version of Maven are you using?

Hey, let me know what you need. At this point, it'll probably make more sense to move to the same project structure that is being used by the Chinese and German books.

Yep, Shane, you caught one of the issues. Hudson + OpenJDK have some small issues. One of them is that the captcha doesn't render correctly, the other is that the SSL interaction during automatic plugin installation doesn't work.

I also write a fair amount of Wicket code and have the same struggles. For example, I'm trying to change the color (just the CSS class) of a particular Label element. While Wicket allows me to quickly throw together some impressive UI, it fails in the last mile of customization when you have a CSS designer who just wants you to do something simple. "Well why can't you just put in a conditional statement that changes the class of the <span>?" .... "It's not that easy."

Thanks for the great blog post BTW.

thanks response@example.com - we're not frustrated with the axe grinding, we're simply going to respond when criticism isn't founded on any rational objection.

Whatever, I'm not going to sit here and read a post that contains some totally unfair criticism of Maven. You call the following statements "well argued"? "The problem with Maven is that I have to learn a Plugin API to write a plugin." and "I don't like the maven repository (so use these other tools that interact with the same repository)."

That fact is that Maven often ends up "holding the hot potato" in an organization. If an org has a particularly difficult build that requires some customization, people continue to try to fit a square peg like the release plugin into a round hole, fail, and then turn around and start blogging about how much Maven sucks. The Site plugin, the Release plugin, even some of the core plugins weren't designed to solve everyone's individuals needs. If you have a release process that doesn't fit the mold, then stop complaining about the Maven Release plugin and start working on your own. Instead what happens is that people tend to blame Maven for inherent problems in a Build. If you are not willing to approach Maven and use its conventions, don't use it.

We have a Plugin API and there are many examples of Plugins throughout the net. People need to stop complaining about how various plugins don't work and start writing the plugins that satisfy their own requirements. People need to stop complaining about the documentation and start participating.

Dave, your central problem is one shared by many. The documentation on the Maven site is akin to the "Red Matter" in Star Trek. Interacting with something like the POM documentation on the Maven site tends to create a singularity of confusion which traps all who dare to read it. We're trying to fix that (right now).

I've been one of the people jumping up and down about the XML format of the POM, but there's a good reason why it hasn't changed. For one, we do need a single format for the POM as it is used for more than just build configuration; it is used by a series of tools and systems that support development (everything from legal compliance tools to repository managers to IDEs). That being said, Jason is working on features right now that will allow people to have more than one view into a POM (one of them being a "scriptable" POM). Because Maven is more than just a build tool, it is a "project management tool", we have to move a bit slower than we would if we were just building a small build tool like Gradle or Buildr.

In terms of verbosity, while I agree that it is a sore spot on the POM format, I think that most people familiar with Maven would tell you that, once you figure it out, the verbosity isn't the problem that bugs you. The central problem is documentation - we're working on it.

I've got Oleg's talk on tape, but the sound isn't as good. Michael, if we can't get Oleg's and Brian's talk published in a timely manner, I'll make sure that we have some other comprable content soon.

Matthew, that's what I was trying to say on the Maven dev list yesterday. Git lowers the barrier for contribution. People who just want to fix a problem and move on will be able to contribute quickly without having to wait for some centralized power structure to grant permission. Esp. for documentation, patch submissions for doc are never turned around in a timely manner because the tools don't exist to easily merge documentation formats.

Hmmmm.... with the exception of checking for this, there is no difference between the example in this section and your own. The && operator evalutes expressions in order, stopping as soon as an expression isn't true.