Fool me once, shame on you. Fool me twice, shame on me. I'm not going to get fooled by Maven again.
I can't express how much grief recommending Maven has caused me. I had a good experience with Maven for Tapestry 5 for quite a while and had the hubris to recommend it for The Really Big Project. TRBP consists of 40 (and growing) modules, all deeply interrelated. That interrelation is killer, it means that most developers have the master project, with all 40+ modules, open at once. That's 80 source paths (one for production code, one for test code), plus class folders, plus an amazing set of dependencies drawn in from Maven.
Maven simply doesn't scale to this level. Sure, the command line build does work in relatively short order (more on this shortly) ... but for day-to-day usage it's all about the IDE, and the IDE support for Maven just isn't there yet, may never get there.
In both Eclipse and IDEA, the Maven support has been very slow, buggy, and unstable. IDEA 7 gets it a bit more right than Eclipse (with the 0.0.12 Maven plugin) because synchronization is explicit. Still, it seems to turn into an endless amount of tweaking, fixing and praying, to keep things operational.
At the core, Maven has a great idea (really well thought out dependency management) saddled with an obnoxiously bad plugin system for performing the build. The obnoxious part is that a build that works on Monday may fail on Tuesday because some new, broken plugin was released into the central Maven repository.
Perhaps the worst part of Maven is the documentation, especially when it comes to writing your own plugins. The Maven team is criminal: their basic methodology appears to be:
- Crank out an XML version of a data structure
- Run a tool that generates a Java interface from the XML (containing no comments whatsoever)
- Implement the class, don't add any comments
- Don't package source with the plugin, as that would almost make it possible to figure out what's going on
- If you slip up and accidentally generate JavaDoc, make sure the link to it on your site is broken
The Maven project site is an embarrassment. The tool supposedly designed for "project comprehension" is itself incomprehensible, due to its scale, the chaos of its documentation, and the extreme lack of engineering discipline evidenced by its maintainers.
Get out while you still can.
I'm now looking strongly at Ivy which keeps the dependency management (including Maven compatibilty) but jettisons the build. It just makes it easy to write your own Ant-based builds with the automatic dependency download.
Hi Howard,
ReplyDeleteDid you consider Buildr?
Eric.
Yes ... my friend Merlyn checked it out. Liked it initially, but it started failing with no error message as soon as he started to use it in earnest. Not ready for prime time.
ReplyDeleteYou could always try Don Brown's approach and make Maven 2 not suck.
ReplyDeleteHow will this move reflect the way http://tapestry.apache.org/tapestry5/ looks and is kept up to date?
ReplyDeleteHonestly, the Maven stuff was the primary thing stopping me from playing with Tapestry 5, driving me to look at alternatives - I had major problems following the directions for getting beginner apps running. I found Grails and it is kinda cool - for my current project Grails is working nicely at least for prototyping, but I would eventually like to get back to trying Tapestry 5 - hopefully things will be stabilized and simplified when I get there.
ReplyDeleteI rewrote my own build scripts in ruby as Rake tasks. Much more stable and easy to integrate new "plugins".
ReplyDeleteOh God, Howard, "The obnoxious part is that a build that works on Monday may fail on Tuesday because some new, broken plugin was released into the central Maven repository", and because lazy one who wrote pom.xml didn't put plugin versions into the pom. What have you expected?
ReplyDeleteEugene -- I expect my build to work. I'm not talking about snapshots here. I'm talking about using the public versions of a plugin and to have it break arbitrarily is a constant annoyance. Sometimes fall down, go boom ... sometimes behaviors change in unexpected and unwelcome ways.
ReplyDeleteI also have to point out that NONE of the examples or documentation I've seen "locks down" the version numbers on plugins.
As far as I'm concerned, there is ONE version number: currently 2.0.8. The release of Maven should be accompanied by a compatible set of plugins with that version number that have been tested and maybe even documented. It should Just Work.
But the Djinn is out of that bottle ... the Maven team has never cared about users, or about making it work or be sensible. And they don't care about their own results, or their own Maven project sites wouldn't be a total mess. They also hide behind a "that's the wrong version of the plugin".
Point me to one fucking piece of documentation that lists what plugin versions are available and how the fuck they differ and then we can talk about which versions I'm using.
Seems like a classic case of a person using something he doesn't understand and then blaming the tool for being broken. Just create a master pom with pluginManagement and dependencyManagement sections and set fixed version of dependencies and plugins, and you'll have reproducable builds. This has *always* been the recommended practice in Maven.
ReplyDeleteSeems to me like a classic case of someone talking out of their ass ... I've been using Maven 2 for several years now, long enough to make a very considered opinion. I mean, I could be lazy and rush to a snap judgement without say, even looking at the available sources (both T4 and T5 build with Maven, using multi-projects, using all the stuff your guys are kicking around). You can put as much duct tape as you want on your Pinto but that doesn't make it a Ferrari.
ReplyDeleteEver thought about moderating your own comments? Seriously though, I understand you are frustrated, but I'm hardly talking out of my ass. If your main gripe is about builds not being reproducable because Maven is downloading newer versions, why don't you just instruct it to use the versions you want?
ReplyDeleteDoes your issue with Maven also mean you are going to drop it from T5's build? I seriously hope not; to me it'd be like throwing the baby out with the bath water. Just stop, breath and try to objectively compare your current position as a user of Maven to users of Tapestry; certainly the latter hasn't been without hurdles either. Still, we keep plugging away and even contribute back because we believe in the concept.
I feel your pain. We are using Ant now for big stuff, because it takes just too much time and knowledge to maintain a Maven build. Even the Ant build is not very simple, but at least it doesn't break all the time. Next time I'll resort to Bash scripts. All this programming in XML is just a major PITA.
ReplyDeleteStrictly limiting myself to Maven-IDE integration, I can tell you from personal experience that Eclipse-Maven integration is a big JOKE.
ReplyDeleteAnd I don't blame maven for it. There can be a lot to say about Eclipse v/s Netbeans (I am comparing only free IDEs here), but one thing I can say is that Netbeans-Maven integration is pure magic. Netbeans supports maven based projects natively (after you have installed the maven plugin). So it only needs a pom.xml. What's more it can even use an external maven installation to build the project for you.
I am not suggesting that Netbeans is better than eclipse, but atleast in the maven integration department, it leaves eclipse way behind.
Just something to think about.
If Maven is so horrible, would you like to come back to Ant ? Or any alternatives ? Official Maven 2 docs is not perfect, it's true.
ReplyDeleteBTW, Maven2 concept is OK or not ?
Ivy is with no doubt a great tool. People say that Maven's dependency management came from Ivy. What Maven 2 did in that department, that Maven 1 did not was already in Ivy.
ReplyDelete(another great flame ahead if someone ever reads that...)
Netbeans Maven support is ahead of any other IDE that I've seen, use it daily on moderate sized projects.
ReplyDeleteMaven brings so much to the table, I wouldn't think of dropping it. Sure there's been some investment in learning how to tame it, but once you do you find there are simply no alternatives.
dependencyManagement blocks to save yourself surprises, purpose-based profiles, understanding the build lifecycle stages, and being CAREFUL about what repositories you add, these are all key to taming the beast.
Yeah, sorry to all who have suffered through the maven builds. I kind of pushed for them in the beginning. Must have been a naive mistake to think that it would actually work reliably...
ReplyDeleteYou know, I'd side with the people that said you should lock down the version numbers if there was even a sane way of telling what versions there are. Heck, I'm not even sure what plugins are necessarily being used to compile, test, package, etc.
ReplyDeleteEven if I were to get over that hurdle, how would I even attempt at knowing when a bugfix was released? Mind you, we're not talking a core dependency on my code, which even then can be overwhelming to track, but a plugin for the build system. I guess my expectation would be that the latest version only fixes bugs and doesn't alter behavior. After all, nothing else changed and as far as I can tell, my POM meets the maven contract.
Don't bother with Ivy, either.
ReplyDeleteIvy doesn't really handle broken POMs very well (I think the one for Tapestry-4.1.3 is broken, actually), whereas maven may very well work with it. The Ivy folks say the POMs need to be fixed in the repository, the repository admins say everything works fine in maven, so you end up with a nice little stalemate where you're the ultimate loser.
I've begun using the maven ant tasks. They're verbose and it's a bit of work to grab artifacts out of both snapshot and release repositories, but it works. So long as you don't try to use 2.0.8 on Windows. Apparently there was a regression there with whitespaces in paths that I hadn't noticed on my Mac. Ahh, another night lost debugging my build system.
Come to think of it, storing the JARs right in SVN doesn't sound all that bad.
Oh, and one last message. We use maven for Cayenne (nearly everyone regrets the move) and ran into a whole new type of problem. Artifacts that we had pinned the version number down to started being kicked out of the repository. These weren't SNAPSHOTS, mind you, just older versions of artifacts.
ReplyDeleteAaah Howard, that post was fun to read. You could post this one on the BileBlog (with one or the other asshat woven in, of course)
ReplyDeleteSeriously: I am rather concerned about such hefty thoughts short (how short?) before an official T5 release. I am eager to try it out again (after having tried T3 some years ago, we all were younger then:)), but such posts make me rather nervous. Or should I say: I feel more and more.... Wicket? ;)
Hi there,
ReplyDeletenow i working one or two months
with maven2 (begun it only in according to tapestry5) ...
i know its not time enough to adjudicate about a tool, so its only my gut feeling:
... its drives me crazy, same like in my beginning with tapestry 3.
but in the opposite to my stumbling in tapestry 3, maven dont arrest my interrest.
maybe i am blessed from the tapestry project or i am simply too
stupid to follow this "hype"
Why have 40+ modules in one project?
ReplyDeleteWe have a 10 module project (Maven 2) at my company, and I consider that a lot of modules for one project.
The rest of our components and libraries have been cut off as separate projects.
Maven also treats it's modules/projects as equals.
It's all a question of inheritance vs aggregation.
Ant is a great and so is the old 'make' tool. But I personally would let anyone of those near my builds.
Even if used in combination with Ivy, bootstrapping and sharing of build scripts becomes a burden.
Perhaps I would consider Ant+Ivy if I was on a small 1-2 person project (with no shared dependencies), then maybe, maybe.. :)
I feel your pain, I used to evangelize Maven but have since become an Ivy advocate.
ReplyDeleteIvy is far more flexible on how you setup your repository and, because building is delgated to Ant, Ivy doesn't try to dictate your project structure like Maven Does
Howard, your criticisms are valid and I've been burned in many ways the same as you have - downloading broken releases, documentation that is flat-out lying, etc., but what's an alternative? Give me another tool that uses convention over configuration, dependency management and copius plugins and i'll consider it. At this stage, it seems energy would be best directed towards addressing your issues (The documentation issue is particularly atrocious) rather than starting from scratch.
ReplyDelete+1 for Ivy. I've been using it a while now. The only point I'd make is not to bother with the whole central repository thing. Make your own repository. Pull down bits from the official repository if necessary but it's much less headaches (and faster) to just host your own repository.
ReplyDeleteI also check my resolves libs into CVS. That may be considered a bad practice but so far it's been more positive than negative.
The problem here is that if you're going to write a "convention over configuration" system, you have to make sure the conventions are sane.
ReplyDeleteThe maven site claims the tool offers "Simple project setup that follows best practices - get a new project or module started in seconds", but the reality is that making a maven build reliable and repeatable requires a significant investment of effort and infrastructure.
Which in itself isn't bad -- building stuff is hard -- but maven does its best to pretend these problems don't exist until you're burnt by them. The default settings are "best practices" until they bite you in the arse, and then some guy shows up in your blog comments to flame you for not knowing the "right" way to do it that's mentioned nowhere in the user/setup guide.
wow, this is a most exciting blog post.
ReplyDeleteIt came to be that I'm writing a multi-module project based on maven using T5's maven structure as a guide.
I certainly do come across productivity bottlenecks in trying to sync my pom.xmls with my IDE(i'm using idea7).
trying to use the built-in synchronization is problematic and doesn't produce errors very well(or at all..especially when it comes to a dependency not being found).
I've found that deleting my project files and exclusively using the command line "mvn idea:idea" tends to work better for synchronizing poms.
The pain with this is I'll need to close my project in IDEA before I run the command. I don't mind when I'm just doing normal coding, but when I'm building poms for submodules it can be a real hassle.
I too was running into lots of issues with different versions of dependencies being brought down and stuff breaking. but then I read a good article somewhere(can't find the link) which basically said to browse the continuum and archiva projects as they are good examples of maven used properly. Well..they should be since I believe they are made by the same people who made maven itself.
After reviewing maven poms for continuum I noticed they used a lot more [dependencyManagement] than tapestry and yes, the plugin versions were typically specified.
Howard's right, the CLI should at least be able to spit out a list of what versions are being used for plugins in which the version had not been specified. and I agree that maven's site is crappy with the docs. and attaching sources for repository deployment should be automatic!
maven could be a whole lot better if the integration with IDEs was better and consistent. for so many people relying on it I'm shocked that the tools aren't better. the same goes for the documentation.
I don't know about ivy, but if it's not incredibly better than maven I don't see the point in switching to anything else. not that you are.
I'm gonna try out using netbeans although i'm pretty attached to IDEA - maybe I'll use it just to sort out pom.xml configurations....the latest version of sun's Glassfish is built using maven so it's no suprise NetBeans would have the best integration.
I can't agree more. Yes, I know Maven inside and out and I still think that Maven is a steaming pile of dog shit on so many levels.
ReplyDeleteThank you Howard for standing up and saying what you have said. More people need to start doing that. Hopefully it will influence others to do the same.
Personally, I have had such bad experiences with Maven based projects now that I refuse to contribute code for any project which uses Maven (because I refuse to use Maven).
Replacing Ant with a Ruby solution isn't ideal either. Buildr is a good idea, but not the right implementation.
From where I sit right now, the best thing would be to do a Groovy based tool set (gant is a good start because it gives you the power of Ant, Groovy and Java in one tool, but it lacks the structure of Maven).
Few things...
ReplyDeleteDo you have anything more concrete than "Maven simply doesn't scale to this level."? There are tons of different ways to scale. Also I'd like to add again that Netbeans has by far the best Maven support. With netbeans, it's really built-in, not a patch on an existing project system.
Many of you are complaining here that maven sucks but without anything specific, that's rather cheap bashing.
Maven problems (especially with IDE):
ReplyDeleteEclipse crashes<
Long (10 - 20) minute start up times, as POMs are processed and dependencies downloaded
Intense efforts to hunt down conflicting dependencies
Huge memory consumption
Insanely bad IDE performance
Unwanted dependencies between projects (that both happen to use Maven)
IDE hangs bringing up the Maven settings panel
IDE hangs opening the project after upgrading the Maven Eclipse plugin version
Broken Maven plugins that fail to work as advertised (i.e., do the wrong thing in multi-module with no recourse)
Plugins that stay as an alpha for 2 - 3 years (though surefire 2.4 finally did come out)
Inability to get any useful debugging information out of some plugins (surefire/testng can bomb out with no output anywhere, no clue what the failure is)
Plugins that break if you aren't using the standard Maven project layout (i.e., are hard coded to src/main/site, etc.)
Utter lack of documentation
... that's off the top of my head.
I think Howard just hit upon another good point. The SNAPSHOT system just doesn't work, IMHO. When used properly, it can be a great way for a project to let early adopters test things. All too often, though, it's simply a crutch preventing a formal release.
ReplyDeleteI can't recall how many times I've run into issues by relying on a SNAPSHOT build of some artifact and have it break on me. The standard reply is "use something stable then, not the SNAPSHOTs." Well, when the SNAPSHOTs are the only place to get bugfixes because a proper release hasn't been made in an inordinate amount of time, it puts one in a bit of tight spot.
Once again, not an issue with maven per se, but since maven makes it so simple to use the SNAPSHOT crush, it's a problem I've been running into with increasing frequency.
Ivy works great, and with Ant 7 imports you can have build files for modules that are just 3 or 4 lines.
ReplyDeleteDrop me a note if you want a skeleton multi-module build that uses Ivy.
Oh, and I agree with the guy that says build your own repository. Maybe I'm just anal and like customizing my ivy dependency files, but its worked well for me for a couple years.
what howard said. +
ReplyDeletethe default goal order (which can't be easily modified)
doesn't work with typical web app deployment cycles:
#1. build
#2. copy ear file to server/default/deploy
#3. start up jboss
#4. run unit tests
additionally, getting maven to properly build an ear (and
everything in between) is a nightmare when it comes to
resolving the dependencies and getting all the right jars
to go into the right places.
writing and figuring out the XML magic to define configuration
for plugins is typically far more code than what I would write
with an ant based build. and it is more complicated. and the
documentation SUCKS. complication is a bad thing.
maven is slow. i had a maven based project which i converted to
ant. maven took over a minute. ant took 10 seconds.
i don't need to generate a static ugly website with far more crap
on it than i would ever care to look at. wiki's are far better
solutions.
by default, there is too much directory nesting.
project/src/main/java/com/kink/blah is absurd.
the idea of central repositories is broken. what if maven decides
one day to change the layout? oh wait, they already did from m1 to m2.
if i check my project out of SVN, i require that my project to build the
same 5 years from now as it does now. using maven does not absolutely
promise that.
if i want customized functionality, i don't want to write some
java code to do it. java based plugins are a terrible idea.
if a maven managed plugin gets a new verison and introduces some sort
of bug or change that breaks my build, i'm screwed and all of my developers
are screwed until it is fixed.
continuum looks nice, but is also an incomplete pile of shit. it has no
concept of build numbers. i need build numbers.
pom.xml files all over the place is fucking annoying. i have an ant
based build for a very large project that drives all 14 of the kink.com
websites that is one single build file that is 858 lines long, anyone
can come in and easily read and extend it. when we did it in maven,
it was about 10 different pom.xml files all over the place and several
thousand lines of crazy unreadable xml. it would have taken a full
maven expert to even begin to insert themsevles into the development
of the application. maven does not follow the keep it simple principles.
i could go on and on, but the fact is that if you can't see what
a pile of shit maven is, then i'm probably not going to convince
you. however, take this as a note... we have been interviewing a
lot of people for java developer positions and not one single
person that we have interviewed has had a truly good thing to
say about maven.
I can't say I do not disagree with the post. I'm working on a 150+ module project using maven and eclipse.
ReplyDeleteWe used to have 30-40 minutes workspace setup every day. That's a lot of resources poured into fetching snapshots and all that. We've fixed it by making an eclipse plugin that figures out the maven modules in your workspace and updating them with a single reactor invocation. That cut down the timing.
Decent Eclipse integration in my opinion is at least 1 year away though a really nice one would not be possible until eclipse finally decides to have nested projects.
The maven-plugin mess is fixable with a master pom (a rather large one) containing every single plugin version you can come up with. Though, I agree that the default version of at least the "official" plugins should be related to the maven version.
Still, I would not throw it out the window (yet). The convention it propagates and the uniformity of the build process across modules achieved only by stating packaging = jar (or whatever) is too beneficial, especially for a company.
Still, if you decide to ditch it, I would not mind, as long as we've got tapestry in a maven2 repository along with correct dependency relationships. ;)
It's good to read you guys after days and days suffering with maven...
ReplyDeleteAt least when there is a bug a want to be able to handle it - and to actually see it and be able to imagine what is happening. Maven adds its own bugs. I don't need them, i already have mine.
I mean : all tools have bugs, no problem, but maven is a central piece in the process of code production. At least i should have been robust.
@John Scott Stevens:
ReplyDeleteI would argue that unit tests are run during the build, and integration tests are run against a running JBoss, but that's a minor detail.
The flow you described appears to match the package phase + using the Cargo plugin to start & deploy + running Surefire on a subset of the test classes during the integration-test phase. Did you explore that?
I haven't worked with ear archives and Maven, but I would assume that it works in general. Maybe you're not scoping the dependencies correctly?
Deviating from the defaults should be avoided in order to keep configuration to a minmum. After all, that's the main idea.
But I do agree that the XML gets unreasonably verbose very fast.
Maven itself is not slow, and certainly not a factor 6 as your anecdote states. Either there's some sort of network wait, or you're simply doing a lot of things such as building archives and whatnot in the Maven build, that you don't do in the Ant script.
The generated site is fairly useless for lengthy documentation, but the generated reports such as Javadoc, Xref, test coverage etc are a nice addition to the continuous integration process.
The layout has changed once in maybe 5 years, and you wouldn't even notice since Maven 2 supports Maven 1 layout. Keeping dependencies in the source control management system puts unnecessary load on the SCM server (70% of the size of a full checkout are never changed by your team),
you lose all dependency tracking, and I have yet to see anyone consistently version the jars, so you end up with stuff like mail.jar (which version was that again?).
Java plugins are a bit cumbersome, but it's possible to run specialized Ant tasks with the antrun plugin.
Plugin versioning is your choice: either use whatever is the latest, or manually specify a version. It's that simple. The option "the latest one that works with my particular projet" is not available.
Pom files in a hierarchial project can be kept small by using inheritance. Also, the pom file is declarative by nature, and they all have the same structure, so it's very easy to read just about any pom file if you know Maven. There's no figuring out in which order stuff happens, because it's all standard.
Ant build files on the other hand, are different in each project, more like scripts.
Maven is a very useful tool, and has worked very well for me in many projects. You will however need to adjust to the Maven philosophy, or else you're problably going to get burned.
If you have the attitude that "Here's my way of organizing a project, and now I'm going to shoe-horn Maven into doing that!", you will be in a world of hurt. If you instead work with Maven, a lot of good things will come for free.
It's always nice to read your post Howard, almost nice as reading your code.
ReplyDeleteBTW Have you considered maven tasks for ant?
> @Peter Backlund:
ReplyDelete>
> I would argue that unit tests are run during the build, and integration
> tests are run against a running JBoss, but that's a minor detail.
In our case, they are the same thing. We only write tests for our business
logic (EJB3 and beans).
> The flow you described appears to match the package phase + using the
> Cargo plugin to start & deploy + running Surefire on a subset of the
> test classes during the integration-test phase. Did you explore that?
Yep.
> I haven't worked with ear archives and Maven, but I would assume that it
> works in general. Maybe you're not scoping the dependencies correctly?
Exactly my point... with ant, I don't need to scope dependencies correctly...
and doing so with maven in a royal nightmare.
> Deviating from the defaults should be avoided in order to keep
> configuration to a minmum. After all, that's the main idea. But I do
> agree that the XML gets unreasonably verbose very fast.
Indeed.
> Maven itself is not slow, and certainly not a factor 6 as your anecdote
> states. Either there's some sort of network wait, or you're simply doing
> a lot of things such as building archives and whatnot in the Maven
> build, that you don't do in the Ant script.
Once again... I must be doing something wrong with Maven in order for it
to suck. Too bad it is so easy to do something wrong with Maven, yet it is
so easy to do something right with ant. Blaming the network for Maven's slowness
does nothing to rectify the fact that Maven is slow.
> The generated site is fairly useless for lengthy documentation, but the
> generated reports such as Javadoc, Xref, test coverage etc are a nice
> addition to the continuous integration process.
Oh and those 5 lines of ant to do exactly the same thing is so hard to write.
> The layout has changed once in maybe 5 years, and you wouldn't even
> notice since Maven 2 supports Maven 1 layout. Keeping dependencies in
> the source control management system puts unnecessary load on the SCM
> server (70% of the size of a full checkout are never changed by your
> team), you lose all dependency tracking, and I have yet to see anyone
> consistently version the jars, so you end up with stuff like mail.jar
> (which version was that again?).
Ah, that is where you are totally wrong and spending the last 10+ years writing
enterprise Java apps has proven this to me. PUT YOUR JAR FILES IN SVN.
It does not matter what version mail.jar is as long as your application passes
its unit tests. It is not like mail.jar changes frequently. Its an API anyway.
As I said before, I want to check out my app from svn and type ant and just have it work. This is a MAJOR benefit when it comes to bringing people up to speed with development.
> Java plugins are a bit cumbersome, but it's possible to run specialized
> Ant tasks with the antrun plugin.
I might as well just use Ant to do my builds then. Where is the benefit of the
added complexity of Maven?
> Plugin versioning is your choice: either use whatever is the latest, or
> manually specify a version. It's that simple. The option "the latest one
> that works with my particular projet" is not available.
Uh huh.
> Pom files in a hierarchial project can be kept small by using
> inheritance. Also, the pom file is declarative by nature, and they all
> have the same structure, so it's very easy to read just about any pom
> file if you know Maven. There's no figuring out in which order stuff
> happens, because it's all standard.
It is a mess.
> Ant build files on the other hand, are different in each project, more
> like scripts.
Which is fine. A build is a script. Each project has different requirements
and therefore different scripts.
> Maven is a very useful tool, and has worked very well for me in many
> projects. You will however need to adjust to the Maven philosophy, or
> else you're problably going to get burned.
I hate it when people tell me that. It is so lame. I've tried the 'Maven
philosophy' and because Maven is such the wrong tool I did get burned. We had to work around bugs in Maven, we had to work around the philosophy of Maven... all to just get a project to build.
> If you have the attitude that "Here's my way of organizing a project,
> and now I'm going to shoe-horn Maven into doing that!", you will be in a
> world of hurt. If you instead work with Maven, a lot of good things will
> come for free.
Nope sorry dude... we totally reorganized a large scale project around Maven
and it failed miserably.
By the way, I do love ant, but I'm not saying it is the best tool out there either. Nothing is. However, when it comes to just getting shit done, ant works far better than Maven.
As I agree with some of the dislikes people have mentioned I really do believe that many of them are a matter of not understanding Maven. Most of that is probably because the documentation is hard to find or is not where most would expect. The documentation is the biggest con I have with Maven.
ReplyDeleteThere are ways to alleviate many of the problems people are having or are mentioning, but they take too much time to find. Time that people are not willing to invest. They want an easy to use tool and don't want to invest much time. I don't think this is too much to ask; however, I know from experience that investing the time up front is well worth it in the end. I have a Maven build system that manages 30+ projects and its pretty damn stable. The only problems I seem to have is when people don't understand Maven. Its a little too complex to just pickup and have a perfect build in a couple of minutes like the documentation suggests. It takes time to understand how Maven works and how it can manage dependencies, profiles, plugin versions, internal repositories, etc for you.
I am not trying to come on here and "flame" you as someone put in their comment here, but I am saying that many of the shortcomings that people mention can be alleviated, but it does take some investment. I think it really boils down to the type and size of the project you are working and how you structure your projects. If you create a project with 40 modules.... well, all I have to say to you is good luck. Why don't you split that up into separate projects and have Maven manage the dependencies? If you need to package the separate projects into one installation then create a new project that does just that. These are just suggestions, as I really don't know everything about the project and won't pretend too.
Maybe people should invest more time before saying something sucks though. Its OK to say, Maven doesn't work for my needs or Maven really just takes too much time to setup and its harder to learn than other build systems. Thats fine. I don't have a problem with that, but don't say it sucks because you didn't spend the time to do it right. The documentation is not perfect, but somehow I was able to have an entire system that works great and has for some time now. I work in Eclipse everyday and I know that the support is sub-par, but I know that's Eclipse's fault not Maven's; therefore, I won't say Maven sucks I would say Eclipse is behind.
If I get nothing else across I hope that people understand that you should give any tool due diligence before writing it off as a tool that "sucks." Do your homework and spend the time up before you say something "sucks."
I had a lot of problems to find how one can have several src direcories for the java files. I really digged into the doc. In fact, two maven specialists explained to me that you must add some plugin to manage several source direcories.
ReplyDeleteI had to trick the config in order be able to have a good MANIFEST.MF file with the good security config (in Maven 1)
Again with maven 1, the goal maven eclipse is proken for the ear.
maven 2 : the two spscialists explained to me that the xml dtd changed between the 2.0.4 and 2.0.5 (maybe it's not the good version numbers) but the dtd version number did not change! Great idea!
Same "black box" approach : few days ago a plugin upgraded, which upgraded several other components in maven, which led for one of them to an immature and buggy version : huge regression! Their project don't build anymore.
I am ok to learn some maven, but here you are obliged to learn it, if you simply want to make it run, and fix several simple things! This tool can make you loose a lot of time.
Lack of documentation, unstable, not solid.
And once again, just like many other guys, i was a very-pro maven. I like the idea of maven very much, but the implementation, and the details are killing.
Next time i bring my own bugs with ant.
I'm not going to argue about plugins, modules,...
ReplyDeleteyes it could be easier if maven locks down the plugins for each release (it has been already suggested and most likely to be done for 2.1) and documentation could be way better.
Regarding the Eclipse integration I'd just suggest Q4E, an alternative to m2eclipse (disclaimer: I work in that project)
It solves several of the problems you mention, others come directly from Maven so not much we can do about. We've just added a dependency analysis tool for next version that should also alleviate some pain.
@Jon Scott Stevens: Discussions on Continuum 2 are underway. Might be an idea to chip in ideas there.
ReplyDeleteI've had some good experiences using mvn eclipse:eclipse to generate standalone Eclipse project settings for a Maven project (ActiveMQ) instead of trying to make Eclipse use Maven.
ReplyDelete+1 for Ivy
ReplyDeleteOur company has mostly migrated to Ivy from Maven build systems at the moment. As I can see the developers are much happier with it.
Maven had a great idea on the ground floor, but it buried by a really bad implementation.
+1 Maven.
ReplyDeleteTo the Ivy folks. Ivy and Maven do have some overlap (dependency management) but they are not tools targeting the same problem. Maven is more of a "building by convention" framework, along the same vein as Ruby on Rails, Django, Grails, et al are "coding by convention" frameworks. Ivy just fetches dependencies.
Maven certainly ain't perfect, but it is open source. You can always hack away at the pain points and make it better.
When someone makes the claim that users of a tool cannot understand the tool after several hours+days+weeks of trying to get something to work, I see that as a failing of the tool rather than a failing of the person.
ReplyDeleteQuote: "Ivy doesn't really handle broken POMs very well (I think the one for Tapestry-4.1.3 is broken, actually), whereas maven may very well work with it. The Ivy folks say the POMs need to be fixed in the repository, the repository admins say everything works fine in maven, so you end up with a nice little stalemate where you're the ultimate loser."
ReplyDeleteI agree that Ivy has some problems with broken (and even not broken) poms. But I disagree when you say that we (Ivy team) say that we ask the repository to be fixed. Ivy supports poms where the metadata is broken (artifactId different from what is supposed to be according to the module location) since 1.3 I think. We spend a lot of time improving our compatibility, even though without a good documentation of what Maven 2 offers for dependency management it's sometimes difficult, and even when it requires strange things. Ivy 2.0 will have a much better pom compatibility, and the latest beta already provides what I think is a very decent compatibility.
The only thing we won't ever accept in Ivy is broken XML, because strangely enough we use an XML parser to parse poms (and you can find broken XML in maven 2 central repo).
Well, first of all, migrating a large existing application from Ant to Maven may be hard, depending on the previous structure. No question about it.
ReplyDeleteOn a greenfield application however, you have a huge advantage using Maven. Stick to the conventions and you'll get a lot of boilerplate setup for free. In my experience, most projects have more in common than not. With a convention-based build tool, you don't have to script stuff such as "compile all my java source code under src/ and send the output to the build/ directory". You may think that you "don't need to scope jars" in Ant, but that's exactly what you're doing when you're defining the classpaths for compilation, testing and deployment.
About the original blog post:
- Don't blame Maven for a bad IDE plugin. Someone else pointed out Q4E, which seems to work better. But I would still recommend running Maven on the command line only, since you don't really need it that often once the project is set up.
- Maven is an open plugin system. There is no central authority on what plugins to include in each release, so occasionally some plugin that you use may break in your particular setup. It works the same way as Firefox for example. There's nothing you can do about that other than changing Maven to stop using plugin, and coordinate a joint release across all the world's plugins.
Yes, some plugins are worse than others. Yes, some plugins are poorly maintained and held in snapshot mode for far too long. But it's the responsibility of each team to specify the version number to use.
> Well, first of all, migrating a large existing application from Ant to
ReplyDelete> Maven may be hard, depending on the previous structure. No question
> about it.
Na, that isn't so hard.
> On a greenfield application however, you have a huge advantage using
> Maven. Stick to the conventions and you'll get a lot of boilerplate
> setup for free. In my experience, most projects have more in common than
> not. With a convention-based build tool, you don't have to script stuff
> such as "compile all my java source code under src/ and send the output
> to the build/ directory".
Right. The amount of pom.xml crap that you have to write is about
equivalent to the amount of ant build.xml crap that you have to write.
However, the distinct advantage of ant is that you *know* for a fact
exactly what is going on. With Maven, it is a HUGE learning process and
it is very difficult without reading through tons of debug output to
figure out what is going on. You might reply by saying that it doesn't
matter since Maven takes care of it all for you. The problem with that
is when something isn't working right. It becomes a *nightmare* to
debug.
> You may think that you "don't need to scope
> jars" in Ant, but that's exactly what you're doing when you're defining
> the classpaths for compilation, testing and deployment.
I honestly see this as a good thing. I can look at a classpath that I
setup in an ant build script and know *exactly* what is going on in a
matter of seconds. With Maven, everything is so abstracted that it is
nearly impossible. Even worse is that I become the only expert on the
pom setup and nobody else in my company can fix the build. Encouraging
one expert ensures job security however I would fire someone who thought
that way.
> - Don't blame Maven for a bad IDE plugin. Someone else pointed out Q4E,
> which seems to work better. But I would still recommend running Maven on
> the command line only, since you don't really need it that often once
> the project is set up.
It is amazing that this is even an issue. For Eclipse, I setup the
project .classpath and .project files and that is it. It is checked into
svn and really does not change much. It takes me 30 seconds. I don't
need something to generate eclipse project settings for me.
> - Maven is an open plugin system. There is no central authority on what
> plugins to include in each release, so occasionally some plugin that you
> use may break in your particular setup. It works the same way as Firefox
> for example. There's nothing you can do about that other than changing
> Maven to stop using plugin, and coordinate a joint release across all
> the world's plugins.
>
> Yes, some plugins are worse than others. Yes, some plugins are poorly
> maintained and held in snapshot mode for far too long. But it's the
> responsibility of each team to specify the version number to use.
So, basically, I see you sayiing that Maven has some serious issues with
regards to quality control and that fixing those is either up to me
(which takes a lot of time away from me actually doing real work) or I
have to nag someone else to do it for me. I don't see how any of that is
a benefit.
It is possible to create crappy ant build files. If you want an example
of a very efficient and well done ant build.xml file for a large
enterprise grade project, take a look at the SubEthaMail project.
http://subetha.tigris.org/ It is simple, well defined and does
everything in 488 lines. I know exactly how everything works, it is easy
for someone else to pick up, the builds happen quickly, it is easy to
extend and it just works.
I can look at a classpath that I setup in an ant build script and know *exactly* what is going on in a matter of seconds. With Maven, everything is so abstracted that it is nearly impossible.
ReplyDeleteNice generalization...you left off a couple of words. Your last sentence should have read: With Maven, everything is so abstracted that it is nearly impossible for me to understand. Their are a number of developers out there who are quite adept at reading POM files.
It is amazing that this is even an issue. For Eclipse, I setup the project .classpath and .project files and that is it. It is checked into svn and really does not change much. It takes me 30 seconds. I don't need something to generate eclipse project settings for me.
Yes but what do happens if your team doesn't use eclipse or you need to do automated builds. Now you have to create your eclipse build AND your ant build. So now you're maintaining distinct sets of settings (or metadata). Whenever I hear someone say that they check in their IDE's settings file with their project I just cringe.
> Nice generalization...you left off a couple of words. Your last sentence
ReplyDelete> should have read: With Maven, everything is so abstracted that it is
> nearly impossible for me to understand. Their are a number of developers
> out there who are quite adept at reading POM files.
'number of developers' is the key words there. How many people do you
think know ant inside and out vs. the number of people who know Maven
equally well? I'd guess at least 500:1 in ant's favor. I have *yet* to
find someone who does not agree that Maven has a HUGE learning curve and
terrible documentation.
As someone said earlier:
"When someone makes the claim that users of a tool cannot understand the
tool after several hours+days+weeks of trying to get something to work,
I see that as a failing of the tool rather than a failing of the person."
And like I said earlier:
"i could go on and on, but the fact is that if you can't see what a pile
of shit maven is, then i'm probably not going to convince you."
Stop trying to defend Maven. There is nothing you can do to convince
me of its value. I've used it extensively and I don't like it.
> Yes but what do happens if your team doesn't use eclipse or you need to
> do automated builds. Now you have to create your eclipse build AND your
> ant build. So now you're maintaining distinct sets of settings (or
> metadata). Whenever I hear someone say that they check in their IDE's
> settings file with their project I just cringe.
If you actually have ever used eclipse, you would know that you don't
use eclipse to build the project, you use your ant build.xml file to
build your project. That is what the Ant View is for. The only reason
why you need a .classpath and .project file is for eclipse to do its own
internal code compilation (which generally goes into a _eclipse folder
within your project directory).
.project files are only a few lines of basic XML that can be copied
across projects with only one line changes. As for the .classpath, all
it contains is the files in my project/lib directory. Not a huge deal to
maintain at all. All of the developers at my company use Eclipse so it
is not a big deal. If someone else wanted to use IDEA, then they can
just check in their own project files. These things change so
infrequently it is not a big deal at all.
In the end, checking everything into svn promises that no matter when or
where I check out my project, I know it is going to build with minimal
effort. If I was a new developer, my process is simply:
#1. Install Eclipse, Subclipse, Ant
#2. Check project out using subclipse.
#3. Drag/drop build.xml into Ant View.
#4. Run deploy target.
If I was a new developer using Maven, there is a few more steps to
complete (which take bloody forever as it has to cache an ass ton of jar
files on my disk) and looking at the pom.xml files would confuse the
hell out of me. If I was tasked with adding a new module, I wouldn't
even know where to start. I would have to come up to speed with Maven
first, then get an understanding of the existing pom.xml files. Lame.
Why do people make things harder than they need to?
Well, migrating an existing application is the hard one. Setting up a new project is easy.
ReplyDeleteThe main difference between build.xml and pom.xml is that build.xml is a script, and pom.xml is a configuration file. I really think that a conventions-based standardized build system is an improvement over build scripting, which is not to say that Maven is without flaws. The pom is unnecessarily verbose, but about 90% of your typical build.xml comes for free with Maven, whereas the rest of the "crap" adds value on top of that - dependency management, project management and so on.
To add to Hohonuuli's comment, I don't even have to look at the pom to know what's going on, since it works the same way every time. The same goes for any developer that is familiar with Maven. This is actually a strong selling point for Maven - standardization means that more people are familiar with the tool, and less reliance on a single person.
Also, the ability to have a single project definition across the command line, the automated build system, IntelliJ, Eclipse and Netbeans is a another selling point for Maven.
If a certain version of a certain plugin breaks a certain build environment, it's generally not a quality issue with the plugin engine. It is up to you to specify a combination of versions that work for you, the exact same way you handle application dependencies. Suppose your build tool automatically downloaded and used the latest published version of Hibernate, and some day one of your database column names becomes a reserved word in HQL, so parts of your persistence layer breaks. Does that mean the build tool sucks? No. Does that mean Hibernate sucks? No. You simply cannot rely on $LATEST_VERSION of anything and everything to always work in all environments.
>To add to Hohonuuli's comment, I don't even have to look at the pom to
ReplyDelete>know what's going on, since it works the same way every time. The same
>goes for any developer that is familiar with Maven. This is actually a
>strong selling point for Maven - standardization means that more people
>are familiar with the tool, and less reliance on a single person.
I have to disagree here. Many of the plugins are extremely configuration
heavy and require an intimate knowledge of the dependency tree in order
to be configured correctly. For example, marking dependencies as
excluded becomes necessary in order for the war/ear plugin to properly
package things together. There is no clear 'documentation' in the
pom.xml file to explain why certain dependencies have been excluded. I
don't mean 'documentation' as a comment, I mean it as a convention. Ant
is the opposite. Instead of excluding dependencies, you explicitely
define them. You say 'this goes here' and you do it in the context of a
target (such as a 'war' target). Thus the 'documentation' is immediately
clear to anyone who looks at it. The level of abstraction in Maven is so
great that it makes it hard for anyone to get their head around it. That
is a failure of the tool design.
It goes beyond that though. By configuring plugins in the pom.xml files,
you are creating a mess of configuration instead of simply defining the
rules to the build. A new developer who has to go back through that
configuration to determine what is going on is not going to have an easy
time of it. There is no way that you can justify that expense.
>Also, the ability to have a single project definition across the command
>line, the automated build system, IntelliJ, Eclipse and Netbeans is a
>another selling point for Maven.
But, the fact of the matter (and the whole point of this blog posting in
the first place) is that THAT FEATURE DOES NOT WORK! It is a
selling point when looking at maven as a product spec sheet, but the
reality when you start to use it is that the bugs and mistakes in
maven's design prevent MANY of its features from only barely working.
Certainly not working the way that I would expect for something billing
itself as a solution to enterprise software development.
>If a certain version of a certain plugin breaks a certain build
>environment, it's generally not a quality issue with the plugin engine.
Yes it is. How can you even begin to say it isn't?
>It is up to you to specify a combination of versions that work for you,
>the exact same way you handle application dependencies. Suppose your
>build tool automatically downloaded and used the latest published
>version of Hibernate, and some day one of your database column names
>becomes a reserved word in HQL, so parts of your persistence layer
>breaks. Does that mean the build tool sucks? No. Does that mean
>Hibernate sucks? No. You simply cannot rely on $LATEST_VERSION of
>anything and everything to always work in all environments.
My build tool does not automatically download ANYTHING. Requiring people
to download files to build something is a terrible idea. It prevents
people from doing offline development and it makes for instable
development environments. You should check everything into svn so that a
build today will work the exact same as a build 5 years from now.
After all of my years of doing Java software development (going on 12
now), it saddens me that more people have not figured out that it is
extremely important to build software that works for a long time.
How many people do you think know ant inside and out vs. the number of people who know Maven equally well? I'd guess at least 500:1
ReplyDeleteHonestly, I think very few people know either inside and out. Most people know enough to get their work done. But since it appears that you're OK with made up statistics, I'll say the number is 210:189 ;-)
If you actually have ever used eclipse, you would know that you don't use eclipse to build the project, you use your ant build.xml file to
build your project.
You may want to look into how our IDE works a bit closer. You do set up a 'build' with your IDE. You can call it whatever you want (compiile, build) but you still define the source directory, output directory and the libraries and directories on the projects classpath. You choose to add an Ant build file for standalone builds, which, while it's a very wise choice, is not required by eclipse. When there are 2 separate descriptions of the your build (IDE config and build.xml), effort is required to keep these in sync. This may not be an issue depending on the size and disposition of your team. IDE's that can read a pom.xml file, such as Netbeans and Intellij, only have a single description of the build and so there's not an issue with keeping the IDE and your standalone builds in sync.
Since you are a dedicated Eclipse user, I can understand your frustration with Maven. Eclipse has poor integration with Maven, and trying to get the 2 to play well together can be frustrating.
Maven has a HUGE learning curve and terrible documentation.
This is one of those memes that once was true but isn't anymore but just refuses to go away. (Remember the good 'ol days when everyone complained how slow Java was?) Maven documentation has made tremendous strides in the last 2 years. The core plugins are well documented and there are free online books at http://www.sonatype.com/book/ and http://www.devzuz.com/web/guest/products/resources#BBWM. The core concepts of Maven are relatively simple, but like anything it takes a little bit of time and use to sink in.
The generation of IDE descriptor files works fine. The point of the original post was that the plugin which runs Maven targets from inside Eclipse doesn't.
ReplyDeleteMy point was exactly that you shouldn't let the build tool automatically download the newest version of everything. You don't do it with dependencies, and you don't do it if you keep jar files in svn, and you shouldn't do it with plugins. Specify the version of the plugin, and you won't have the problem that the environment breaks on Tuesdays.
Perhaps the source of the problem is the fact that Maven allows you to leave out the plugin version in the first place.
There's no added need of online capability with the Maven dependency model. You need the network the first time you checkout and build a project, and whenever there's a new dependency, same as with jars-in-svn. The upside is that since the size of a checkout is a lot smaller, you can checkout new branches on a slow connection a lot easier, when only a small fraction of the dependencies are different from what you already have in your local Maven repository.
Xavier,
ReplyDeleteI may have misspoken, but I was talking based on experience. For what it's worth, I was referencing the following thread:
http://markmail.org/message/cbmql36klgv6xqan
I also had issues with POMs with classifications, but I think this has been addressed.
All in all, I spent probably 2 - 3 days trying to move over to Ivy (2.0.0-alpha1, IIRC) and ended up having to add a lot of JARs to SVN anyway, because I couldn't get Ivy to download them.
If this has improved, great. Maybe I'll give it a go on my next project. But, my first impression wasn't all that great *shrug*
Kevin,
ReplyDeleteIn the thread you reference, my answer is that you can disable consistency checking in Ivy as a workaround, so this kind of bad metadata is supported by Ivy, even though this is not the default to accept this kind of things.
That being said, I don't say that using the current version of Ivy works like a charm with Maven 2 repository. What I say is that we don't wash our hands by rejecting the fault on the repository. We do work to make Ivy compatible with maven 2 repository, even when it means accepting crappy stuff. So we still have some work to do, but 2.0 final should be very good in this area.
Fair enough.
ReplyDeleteThis should be the default then. As a user, I have no way of knowing that there's a problem until my dependencies don't resolve. At that point, I have to try to track down why this is the case. Was it a bad groupId? Bad artifactId? Does the repo not have the artifact? About the last thing I'm looking for is a problem with the POM and a semi-documented switch that lets the resolver handle this better.
Like I said, if this situation has improved, great; I retract my earlier statement. My memory is a bit hazy, and I may very well have just moved on after someone suggested my only real recourse was to set up a private repository, too.
I understand your concern, but from my point of view having a default which accepts bad metadata encourages bad metadata... Maybe we could make this the default for our maven 2 resolver only.
ReplyDeleteAlready mentioned in one of the comments; Don Brown...
ReplyDeleteHe has posted New information that might come in handy
I think you misunderstand. I wholly agree with you on principle. The problem is, I just need to get my work done. If Ivy is my tool of choice and it can't help me out, then it's not doing its job. Being principled doesn't download artifacts.
ReplyDeleteI realize that may be a harsh view to take, but I can't control the central repo and I don't believe anyone in the Ivy project can either. The bad metadata gets in there because maven2 copes with it, but because maven2 does cope with it, there's little motivation to fix the broken metadata. So, the exact situation you're trying to prevent is occurring on a completely different front.
Anyway, I like the idea of Ivy in general. If it can be made simpler to switch from maven2, I'd fully endorse it. +1 on making it more resilient to bad maven2 metadata by default.
Here is another good example of something that would frustrate the hell out of me if I had to deal with it...
ReplyDeletehttp://blog.qoqoa.com/2007/07/10/going-java-15-with-maven2-based-project/
another good post...
http://fishbowl.pastiche.org/2007/12/20/maven_broken_by_design
@jon scott stevens
ReplyDeleteDude, you've got some issues. Let it go...go use Ant or Make or whatever works for you.
I agree with Peter a million percent, except with the remark that "the point of the post was that the plugin which runs Maven targets from inside Eclipse doesn't". Howard's bashing the tool as a whole because of failures of integrating it into another one. Not that I'm defending the use of Maven; yes, I know the integration with Eclipse and IDEA is crap and documentation could be better, but that's hardly a a problem with Maven itself. Also, clearly the dependency resolution in Maven with non-versioned dependencies is a problem and I've been burned by it before but I've learned to cope with it by explicitly declaring versions and I expect Howard to do the same. I mean 5 out of 8 top deficiencies Howard lists are related to IDE integration and the rest are related to dependency management, so it's just out of line to blame the core tool itself.
ReplyDelete"Talking out of his ass" Kalle
Does anyone ever tried mvn site:stage or mvn site:stage-deploy !?
ReplyDeleteFrom:
http://maven.apache.org/plugins/maven-site-plugin/usage.html
and
http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why%20doesn't%20the%20links%20between%20parent%20and%20child%20modules%20work%20when%20I%20run%20'mvn%20site'?
you should use stage when you want to preview the generated site locally before a deploy or when (like me) would like to look at new docs without having to wait for nightly docs to come up.
Well it simply don't run.
The statge-deploy override the content of the deploy target directory with the content of the last generated module and the stage does not put eveything in target/staging of the parent but leaves each module into its own target/staging directory.
The exact contrary of what is stated into the FAQ.
@massimo
ReplyDeleteI could only get site:stage to work the way I wanted by using the stagingDirectory argument.
mvn site:stage -DstagingDirectory=c:/temp/site
I have to agree with Maven's IDE support being bad.
ReplyDeleteHowever, if I were in your situation, I won't use the IDE in the first place. Instead I would just use mvn eclipse:eclipse and let it build my .classpath and .project file for me automatically.
Normally I won't be changing the pom.xml file that often once I get a stable base to work on. So the need of the Maven IDE is kind of moot. However, when I am starting a new project I may need it.
Hi
ReplyDeleteI've been working on a TRBP of about the same size for a few years. We've not been able to find suitable alternatives to maven. Instead we've learned a few lessons about using maven in large projects:
1. Maven2 is a major improvement over maven1.
2. Set up a local snapshot repository AND let ONLY the build server deploy to that repository.
3. The only build server that actually works is hudson, even though the maven2 integration is somewhat surprising. For instance, it easily deploys modules where tests are failing, since, by default, failing tests are not sufficient to be considered broken by hudson.
4. DONT use parent poms, at least not use more than one level of parents.
5. DONT use built-in maven support in IDEs. Instead, generate the workspace from the poms using idea/ecplipse plugins (sorry netbeans users).
6. Since you don't use parent poms, set up special workspace poms to contain the IDE workspace modules (for workspace generation). These are typically sub-project specific and with a name like customer-workspace.xml (not pom.xml).
7. you CAN have local libraries in the version-control system and mount "file://./libs/" as a repository in the pom. However, few version control systems handle lots of binary data very well (and especially neither of cvs and subversion), so we recommend to stay away from that unless it is absolutely necessary.
eirikima -- good luck with that. I'm building out a new client project; we'll use Maven for dependency management, but only via the Ant tasks. We'll include a "setup-libs" target that uses Maven to download libraries to a local folder. After that, no more Maven, just Ant and the IDE.
ReplyDelete@ Hohonuuli
ReplyDeleteTalk about a cop out, you don't respond to either of the links provided, but utter a lame "Dude you got issues, go use Ant or Make"?
Because here's the thing, that's what people will do, see my comments below on Ant4Eclipse, Jam and Boost.Build.
@kalle
I think trying to sluff off the comments as "IDE related" doesn't cut it with Maven. If one would bother to read the comments from other respectable folks besides Howard, you'd read this from Graeme Rocher
"I think only Java people would be willing to accept a build system like Maven with all its complexities. Any other community would be like "what the hell is this?". For me Maven is the EJB2 of build systems: over complicated, over engineered and requiring an intelligent, code generating IDE just to work with it."
Personally, I'm an Ant fan, having switched over from make. Sure there are issues with Ant, one tool that makes life much easier with Eclipse is ant4eclipse. And using make? Actually not such a bad idea, and we've come along way, consider these tools:
jam
Boost.Build also uses the jam language, and the plan is to rewrite the implementation in Python.
href="http://www.boost.org/doc/libs/1_35_0/tools/build/v2/index.html">Boost.Build
We created Meister a.k.a. Openmake to prevent a lot of the issues seen here with Maven. It is simple, has great Eclipse plug-in support and the fact is that it is widely used in larger companies to provide standardized repeatable builds.
ReplyDeleteJust as an example, if you have insurance from one of the top 20 companies, there is about a 30% chance the software for claims, billing, etc. was all built with Openmake.
I blog on Meister/Maven comparisons and Maven issues as well at the OpenmakeSoftware site under 'Mavericks' build blog.
Look at Gradle, it uses Ivy for dependency management and you can use any ant task. But it adds more:
ReplyDelete1. the build scripts are in groovy, so you have a real language to code the build logic in
2. there's a plugin system which allows plugins to add targets and methods to the build as well as a 'convention' object that defines common paths, properties, etc. building a jar file is just using 'usePlugin("java")' in your build file
3. every module is represented as an object together with the rest. this means you can manipulate all of them together (to set some common attribute, etc.), create cross-module dependencies, etc.
4. in particular, you don't need to have a build file per module, you can write all your logic in one root build file, but if you do want to separate, then the sub-module build files inherit properties and methods from their parents.
5. you can redefine targets. so if a plugin adds some targets, with dependencies, but one of them isn't exactly what you need, you can just change it.
I was in charge of the project at kink.com that Jon Stevens is ranting about. He's 100% right. Not only is Maven buggy pile of crap, it's deeply flawed *by design*.
ReplyDeleteWhat Jon didn't mention: We hired a Maven expert to work on this problem. He spent a month working on our build system, and in the process submitted several patches for core plugins. It is not possible to say "we didn't understand Maven"; few development teams have the kind of resources we directed at the problem. Still, the system never worked right.
It was obvious at the time that nobody was using Maven for hardcore enterprise j2ee development because the EAR plugin was broken. The whole Maven dependency model simply does not work with EAR files; some JARs need to be put in WAR files and some JARs need to be put at the EAR level, despite the fact that there is a compilation dependency at the WAR level. You're back to determining the dependencies for each little piece by hand, and that part of the EAR plugin didn't work.
Furthermore, the whole lifecycle presumes what I consider to be a fairly trivial environment. In our world, unit tests are run against our business tier API (the EJBs). This API has no hope of working outside of JBoss - good luck trying to mock up persistence services, message queuing services, web services, lifecycle services, and everything else the container gives you. So packaging and deployment *must* occur before unit tests. The rigid Maven lifecycle simply doesn't grok this.
The fact that otherwise-sane developers actually make their build depend on the presence of third-party repositories boggles my mind. In ten years, I want my code to still compile. Do you seriously think those public Maven repositories will still be around in ten years? Do you think the people using Maven 1 repositories thought the same thing? Yes, you can fudge Maven to use a private repository in SVN - which we did - but it wasn't terribly easy or natural.
Philosophically, I think Maven had a kernel of a brilliant idea. Instead of Ant's simple task-based structure, they created this neat idea of an artifact-based structure and seem to have assumed that all the tasks would be pretty much the same. Since the authors of Maven seem to lack experience with anything harder to build than a simple WAR file, those of us with projects more complicated are screwed. Oh, if you want to do something special you can spend a month studying the inane plugin API and write some plugins in Java... no thanks.
I'd really like to see a build system with two high-level concepts: Tasks and artifacts. Artifacts should be able to depend tasks and other artifacts. Tasks should be able to depend on artifacts and other tasks. I'd like a lot of "stock" tasks included in the system. Most of all I'd like the build instructions to be defined in a language like Groovy rather than some mishmash of XML and Java plugins.
Then again, I'd also like world peace, programmers to be adored like sports figures, and, oh, throw in a pony for good measure.
Of course you don't like Maven, you haven't even taken the time to sit down and learn about it as demonstrated by the fact that you continue to talk about problems that have been addressed.
ReplyDeleteIf you don't like the Maven site (I don't), then here's a free 600+ page book. And, if you are having a difficult time figuring out dependency conflicts, load the current dev snapshot of m2eclipse, open up a POM and click on dependency tree.
Can't be bothered? Fine. But, please stop whining about it.
Tim,
ReplyDeleteYou're way out of line. If you had bothered to read my original post, or even a smattering of the comments (by myself and others) you'd be aware that I have extensive experience with Maven, enough to appreciate its strong points ... but also enough to damn its egregious errors.
Howard so comments like "Sounds like someone talking out of their ass" and sentences that include "get out while you still can" are somehow not out-of-line. If you are going to escalate from a position of ignorance, don't be surprised when I call you out on it.
ReplyDeleteAnd, yes, I'll stand by the fact that you don't really know the Maven you've decided isn't sufficient for your needs. Criticism of Modello aside (ok, don't like Modello, let's talk alternatives).
Tim: Why should someone read a 600+ book about a build tool?? We're not talking about 600+ pages to understand esoteric plugins, we're talking 600+ pages to understand basic functionality. Don't you think it is too much?
ReplyDeleteAlso it is way too heavy. It spends forever parsing xmls, starting child containers and injecting properties. Try to create a plugin that does nothing (for testing) and attach it to a multi module build's parent. See how much time Maven adds (for me, for a plugin with total 'execute()' time of 139 milliseconds, maven added 2 seconds. That is ~1400%).
So not only does it take up my time, having to read 600+ pages to understand it, but it takes my time waiting for it to compile my code.
Ittay Dror, you don't have to read all of the 600 pages just a few, let's say 30 or maybe 50. But, do me a favor, don't read any of the pages, just use the tool that you want to use, and stop creating empty plugins as a "test".
ReplyDeleteOMFG, 2 seconds to run an empty plugin. Man, I'm so sorry. Next time I'm talking to the Maven devs I'll tell them that we should add the "empty plugin running under 136 milliseconds benchmark so ittay dror doesn't have anything asinine to say about Maven" unit test. Seriously, how long did it take you to come up with this empty plugin benchmark?
Tim: all plugin times add up. These two seconds are on a 2.4G dual core cpu. On a project we're working on there are 43 modules. After the initial compilation, when nothing has changed, maven takes a minute to run. On a Solaris machine it takes 5 minutes. 5 minutes of doing nothing, since there's nothing to compile. Now, read again my empty plugin suggestion and lets drop 1400% - the actual execution of plugins probably takes 21 seconds. Now, waiting 4.5 minutes after each small change, instead of 21 is unreasonable.
ReplyDeleteAnd one more thing Tim: Do you really think your attitude will make anyone use Maven? I don't mind discussing views, but the way you write is insulting.
> On a project we're working on
ReplyDelete> there are 43 modules. After the
> initial compilation, when nothing > has changed, maven takes a minute > to run.
Wait, then what are you doing wrong? I have a 30 module build, running compile when everything is already compiled averages about 1s per project for the NOOP condition (nothing needs to be done).
> Do you really think your attitude
> will make anyone use Maven? I
> don't mind discussing views,
> but the way you write is
> insulting.
I'm so so sorry. Please forgive me for insulting you. Seriously, you insult me when you ask rhetorical questions like "do you expect me to read a 600+ page book?" No, and, honestly I'd be happy if you didn't read it and left the advantage to others.
In my current company we use Maven for our builds, we have some problems with the tool itself, but we usually can get around it after some hours fighting (sometimes we just give up and go home), but what really annoys me is the Maven + Eclipse integration.
ReplyDeleteIt annoys me so much that I reinstalled eclipse and I didn't even bother downloading the m2eclipse plugin, I run the "validate:copy-dependencies" plugin and I add the jar files to the eclipse project as we did before with ant + ivy.
I kinda of like the global repository, I kinda of like the fact that it forces you to have an organized project and tests that actually have to work (except that you can't have a class named TestUtils on your src/test/java folder), but it's like I read in other blog - sometimes you fight with it and you have the impression that it may win.
I'm starting to turn away from Maven as well. As far as dependency management goes, it's a great concept and (sometimes) works really well. The build-process though is more often a hindrance than a help. Like has already been mentioned, "convention over configuration" is fine, in concept, but since the Maven team is doing such a piss-poor job of documenting which "convention" they refer to, it just gets horrible. As it is now, the only thing it does is force me to conform to their enforced layout and configurations, which really annoys me. Add to the fact that a Maven pom usually ends up just as verbose and confusing (if not more) as an Ant script, at least Ant is flexible enough that it lets me adjust the build-process to my project rather than the other way around. I've used the Ivy/Ant combination in the past and to me, it's starting to look more and more like "the least bad of both worlds".
ReplyDeleteOn a side-note, and this is purely anechdotal, I'm getting a sense that the Maven is starting to have a negative impact on dependency management as well. It used to be that when someone developed a library, they had to actually put in documentation all the dependencies (and yes, supported versions). Now, more and more, developers put their dependencies in the pom and reason that anyone using their library shouldn't have to worry about 3'd party dependancies since Maven will take care of that. Well, I want to worry about that. I want developers to actually have to document external library usage and maybe go through the effort of adding a line or two about WHY they used that particular library. A product or system lifecycle can easily span 5 years and I get nightmares thinking that I'm actually relying on Maven and it's repositories to still operate with full backwards-compatability for such a long time.
Yea I did the same mistake than you, recommending Maven and then regretting it. I will not use Maven again, ever!!
ReplyDeleteIvy for dependency management is all what is needed.
Maven = Ivy + well written generic Ant build file.
ReplyDeleteAvoid the pain of maven and go straight to ant/ivy
Hello,
ReplyDeletewe had unreproducible builds problem in our company with Maven2. There was more problem with unavailable repositories for dependendencies than with plugin dependencies.
However when we started using Nexus (nexus.sonatype.org) for storing deps, there were literally no more such problems.
I suppose it's not a good solution for open source projects, where developers are from various locations, but as for company it does job well.
Regards
Reading comments above I figured out the right way for using Maven. Blame it hard and don't forget to mention your problem. Then some Maven champion comes up and fills gap in documentation.
ReplyDeleteSeriously. They should consider renaming pom.xml to crap.xml.
ReplyDelete