I’ve been doing a lot of work with Maven recently, and having a miserable time of it. Earlier this week I was ranting about it on a mailing list I was on, when I thought it would be therapeutic to try to list 100 things that irks me about Maven 2 that I’ve personally ran into. So, I didn’t come close – I only came up with 25. But I do feel much better now.
Here goes, in no particular order:
- The Maven AntRun tasks allows you run ant from within Maven, but you have very limited access to the POM.
- If you have a multi-module project configuration, changing the version of the root project requires you to change all the versions of the sub-modules
- Maven Ant Tasks doesn’t resolve transitive dependencies exactly the same as a regular Maven project does.
- Maven manages adding all the dependencies you need… and then some. You end up probably spending the same amount of time having to exclude the dependencies you don’t need, especially in EAR/WAR setups
- You pretty much have to declare the versions of every Maven plugin you use, or risk your build breaking when someone updates the plugin.
- You can’t create a ‘macro goal’ that is a chain of multiple goals
- Your custom plugins might not work if it is organized as a sub-module of a project. Inexplicably, if you run the build inside that sub-module it works. (Might just be a problem with Ant-based plugins)
- Maven goes out of its way to not use Ant. So, some things that work correctly in Ant don’t in Maven (for example, building GNU compliant tarball with the assembly plugin)
- You can activate build profiles based on OS, file existence, and environment variables in Maven, but how do you disable them?
- You can configure the build to deploy additional artifacts (e.g. javadoc and sources), but it won’t use the repository or snapshot repository configured for your project
- Figuring out how a build works from reading plugin declarations is not easier than reading an Ant script
- Good luck trying to find the artifact that you need to fix your NoClassDefFoundError
- Passing Maven properties to your AntRun configuration? Bah! who needs that?
- What happened to my Maven 1.x pre/post-goals? How is attaching plugins to build phases a better solution?
- Multi-module projects is like having old school recursive Makefiles
- Why can’t I define variables other than artifactId, groupId, and version to be substituted when building from an archetype?
- Why can’t all the files in archetype-resources be included in the archetype? Why do I have to define them all in an archetype.xml as well?
- Versions of dependencies with classifiers are not be inheritable
- Extending a build is difficult without creating a plugin, which requires creating yet another project
- Customizations to the build always seems to take a few takes of trial and error before you can get them working.
- Configurations specified for an Ant-based plugin doesn’t work if they’re specified at the execution level or the build profile level. They will work if you specify them globally
- Maintaining updates of plugins and what bugs are fixed in what version and what Maven version it’s compatible with is a PITA.
- Documentation sucks. Pretty much everything out there is surface deep. There’s 50/50 chance that features that are skimmed over in the docs won’t work as expected
- Why does the site:deploy and site:stage-deploy behave so differently for multi-module projects?
- Why are build profiles inheritable?
So I imagine some of the explanation are vague, but my experience is that it is par for the course when you deal with builds in Maven. Sometimes there’s seemingly no rhyme or reason for why things don’t work, and by the time you do find a workaround that does, you just don’t want to spend anymore time figuring why your previous approaches didn’t work. I supposed the open source thing to do is to help fix the problem, but honestly, I just don’t love Maven that much.
{ 1 trackback }
{ 8 comments… read them below or add one }
So I’ve had reading this blog post on my to-do list for the last week. I think you hit every nail on the head of all the BS we’ve had to deal with from Maven2 over the last six months. Gah, I hate Maven2; in fact, I think they set us up the bomb.
If I understand #2 correctly, I think you are mistaken. You can use properties to solve this problem. Just define the version in the parent and reference it in the children. You can then change the version in the parent without having to change it in all the children.
Isn’t #5 a benefit instead of a drawback? Avoiding unexpected breakage is the point of specifying an explicit plugin version number.
#13 is false. I’ve been able to use properties such as project.build.directory in my AntRun plugin configurations with no problem.
Using properties in #2 is a hack. If you want to change the version of the parent POM, you have to update all the child POMs to reference the correct version of the parent. The hack is that ppl workaround this by setting the parent POM to a version number that never changes. Doing this makes it harder for people to understand what’s going on in the build unless they know of the workaround.
I would say #5 is a benefit and a drawback. It’s a drawback in that when you update Maven, it’s not real easy to figure out if your existing versions of the plugins work on the current version of Maven, or even what versions of plugins works well with each other.
As for #13, I can only say it didn’t work me. And I’m too far removed from it to want to recall. I’m sure the simple cases like project.build.directory work, but not necessarily useful edge cases. This is a common pattern with Maven. I do remember that everything on this list I looked into pretty thoroughly though, going into the Maven source if I have to.
-Calvin
For #2, this plugin might be what you’re looking for:
Versions Maven Plugin
Wow, you must love ant so much
I moved to Maven to get away from Ant. I also found that Maven and Ant doesn’t really go together that well. And although it is much easier to write maven plugins in Ant, it is much better to write them in Java or other technologies because of the Maven-Ant inconsistencies you described above. When you move to Maven, think Maven not Ant.
My main issue with maven in the past has been its documentation (your point #23), but in my opinion it’s been getting better since the appearance of books like Better Builds with Maven and Maven the Definitive Guide.
Resolving artifacts for NoClassDefFoundErrors (your point #12) has also gotten a little easier since the appearance of jarvana.com. If you’re in Eclipse, the m2eclipse plugin can perform similar searches.
Maven has a steep learning curve, and I can still get frustrated trying to figure out to configure my pom files, but I still think it’s a great tool, and the price is right.
Wow Maven sucks pretty bad. About time people started realizing it – I remember years ago (you can still find the posts online) when people would rave about it and swear by it. Any bad words said about it would be immediately pummeled by a mass following of Maven fanboys rationalizing and making excuses. Now, years later, where are we? Maven sucks has become a common phrase which many people agree with now. AJAX (btw AJAX sucks) is going down a similar path now, only the ‘framework bonanza’ has managed to stave off people’s realization that it, in fact, does suck. DOM/DHTML/JavaScript – what a pile of crap. The realization will come here too, once the hidden costs appear, and once the jokers (probably the same responsible for EJB2..) start getting bored of constantly updating their “AJAX frameworks” (and all the applications dependent on them to fix various browser problems), ‘The Search for the Next Big Buzzword’ will begin.
When will we learn that there is no magic bullet in IT? When will we learn that complex “magic” black box solutions and “fully automated autoconfig super code generating database agnostic multi-platform one-size-fits-all perfect solutions” are simply an unrealistic fantasy? When will we learn that sometimes the “quick hack” (AJAX) shortcut to getting something done usually ends up backfiring at the end of the day? (Hint: Use a VM!)
Really…. Maven? Stop wasting time with this rubbish, spend a few minutes to create a custom Ant build file, and spend some time working on the actual task at hand.