Mike Spille has written an article about Ant 1.6 at TSS (see post here).
One comment from the article:
And with any luck, maybe the <import> task will be the final nail in Maven’s coffin!!
Ok, first I’ll set my own position straight: I think Ant is fantastic at what it does and the basis of a lot of Maven’s plugin functionality uses Ant to provide the tasks.
Apart from the truthfulness of this statement, it’s obvious that Mike hates Maven, and that he’s not alone. So why do you hate maven?
To be honest I hear complaints all the time but rarely see anything that gives a balanced reason for it, so I’d love to hear what really is the cause of such passion about it.
I can think of a few reasons and have taken a bit from those postings, and I’ll start with the biggest one:
Because you hate Jelly
Well you’re not alone! As has been mentioned, even the author has publicly apologised for it and moved on to better things.
It has its fair share of bugs and Maven bears the brunt of this a lot. Having said that, it does do some things pretty well once you get used to it and you can get by in Maven without ever needing to use the nasty bits.
And there is light at the end of the tunnel: future versions of Maven will support other scripting languages.
So is it just Jelly that disgusts you, or is it something else?
Because Maven doesn’t improve on Ant
I’ve heard this too. Everyone seems to think that automatic dependency handling, unit testing and reusable components are easy in Ant (especially with the new 1.6 features),
Howeverm this is usually by cut-and-paste from some other build. Being able to &t;import> a custom component will only yield the same problems Maven has about customisation complaints (see below).
And I’ve seen too many bad Ant build scripts (and this example is by no means the worst)
to think this is true.
Because Maven doesn’t let you customise your build
Ok, maybe this is a lack of documentation, but what sort of customisations do you want to do that you can do in Ant and not easily in Maven?
(the stumbling block in many cases here may be Jelly too, which is fair enough).
Because Maven just generates useless project sites
Yes, a lot of the documentation isn’t used as often as it could be. And you may think the Maven web site is ugly and being inflicted on unsuspecting projects everywhere.
But it is achieving its purpose. I bet if you have used one of these sites, you know exactly where to go to find the CVS information, the developer list, or the javadocs on any other similar project.
The sites can definitely get better, but there are certainly worse out there too – it’s better the devil you know in my opinion.
What would make the generated sites more useful to you?
Because it has a bad reputation of being slow and buggy
At least one poster commented that they hadn’t used Maven but that it just has a bad reputation.
Is that what worries you? And what would put your mind at ease and give Maven a try?
Maven has been radically improved of late and is taking strides forward in this area.
It is now faster and uses less memory.
Most of the common bugs that have bitten people have been fixed. The few that haven’t been fixed have a documented reason as to why they will be treated in a later version (this is always because there is a decent workaround and it doesn’t fit the current schedule and architecture).
The team are actively working with large projects to help them overcome issues and take the tool forward.
Because of something else
Post a comment – let’s not make this a flame war, but constructive criticism is welcome here.
Brett Porter 
One of the big issues I have with maven is how often it breaks. Note that I do assign the blame appropriately; more often than not this is the fault of the project, not a bug in maven. I’ve had to use maven to build any number of projects, and invariably, something breaks or doesn’t work.
The stuff ranges from badly declared dependencies, to outright missing dependencies. JIRA for example even has/had stuff like circular dependencies, so you can never actually build the whole thing from source, due to the module isolation (module A depends on module B depends on module A, the ‘workaround’ is to have a binary of one of these lying around to build the other, then use the new binary to rebuild the original!)
There is also somewhat of an unpleasant learning curve. Even the loudest of ant detractors knows that all they have to do is run ant -projecthelp for any source tree and they’d be told exactly what target to run. In maven, there seems to be a requirement to be part of some inner cult to find the right magic words to get it to do what you actually want. Is it jar:jar, war:jar? web:war? war:dist? How do I clean stuff?
Of course, there’s also the issue of structure. I personally shudder every time I see that dreaded ‘target’ directory, more often than not containing yet another copy of the source, along with seemingly a copy of the entire project! No matter how clever or fast maven becomes, a copy of the whole project will always be slow.
Finally, the attitude of maven fans and developers leaves a lot to be desired. This is the very first time I hear ‘ok, why do you dislike maven?’ vs the more traditional ‘you idiot, maven is the best!’. My first exposure was almost a year ago. I had very politely pointed out a few small changes that’d make maven run a lot less painfully on OSX (eg, not forcing the user to define env vars, as on OSX you KNOW where the JDK is). The response? I was told I should complain to apple and get them to fix OSX and not hardcode the location of the JDK, because ‘that’s broken’. Is it any wonder that so many people despise this tool? What’s more amazing frankly is that there’s anyone who actually likes it!
– You can’t have more than one source directory (without hacking things)
– Unit tests are forced to be off in their own directory (can’t be mixed in with source)
– maven -g does not list the goals in maven.xml
– dot separated variables in expressions are still broken in jelly
But I actually like maven (don’t care for jelly).
Hi Hani. Great comment – I can’t fault any of your points.
I looked up your complaints about OS X and only found a forwarded post from OS-webwork on the maven dev list. I’m sorry you got that sort of response, because someone else posted it to JIRA and it got fixed in Feb: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-1130
Reading through that mail you did send, I think those complaints should be satisfied. We find it hard to break the habit of users building from CVS, but that seems to go well now anyway, and the releases are stable enough to use out of the box.
As far as what you’ve said here – I think better documentation would solve the “magic” question which is being worked on. A cut down version of maven -g might be more useful than the current long output.
Copies of sources is rare but I think it does happen. I don’t believe I encounter it on a day-to-day basis. I know building a webapp does do this, and this is worth investigating.
As far as dependencies go – I’ve seen far worse examples written in Ant where you need to manually locate 18 jakarta-commons JARs, and write up a properties file to reference them. And take a stab in the dark at which version to use. I am loathe to download non-Maven open source projects unless they come bundled with the JARs – but even then I’m amazed to never see any versions attached to them.
Circular dependencies is probably poor design on the user’s end, but it could definitely be handled better by Maven. Not so much circular, but transitive ones where a -> b -> c. We’re targetting that at future versions beyond 1.0.
Thanks again for your fair post!
anon:
– on source trees, this is actually being reconsidered. Although having done things that way in the past there’s a good reason to discourage it. Bear in mind that those things are possible, just discouraged and require more customisation than might otherwise be offered.
– on dot properties: yeah, jexl sucks at that (the culprit used by jelly). The is actually a couple of decent workarounds, but I sure wish it were fixed.
– maven -g and maven.xml. I had a stab at that bug. Its easy to fix if you wait around for all that stuff to be processed (whereas plugin goals are cached), so I may add a new option (-projecthelp? 🙂 that does this and cops the small performance hit.
Thanks!
i don’t hate maven.
in fact, i think we all wish we could be maven mavens.
maven is fairly complex; there’s nothing wrong with that.
but it implies a long learning curve with no immediate return on investment. combine that with the typical pressures on developers to deliver the world yesterday and the result becomes no significant adoption of maven.
personally, i’m waiting for a whole book dedicated to maven to come out. i hate having to dig for doco.
i think that hatcher’s book ‘java development with ant’ (manning) was a catalyst for the mass adoption of ant.
Hani’s right. The basic problem is that maven is too unpredictable. Personally, I have a, say, 40% success rate compiling programs built by Maven. Inevitably something goes wrong; either a dependency can’t be downloaded or the build will crap out. I suspect this is a combination of Maven’s bugginess (it’s been beta forever and now it’s being largely rewritten just to go 1.0 … says a lot about the codebase), Maven’s poor documentation, and people using Maven incorrectly. Anyways, every time this happens I curse the project for not providing a simple, reliable Ant file that I know will Just Work.
Lastly, I don’t think anybody really understands the value proposition of Maven. Not even the Maven developers apparently. Maven shouldn’t be sold as an ant-killer. And your point about dependencies is silly; anybody who’s read Eric Hatcher’s book knows you can do very powerful dependency management with plain old Ant. For Maven to be successful it needs to do what Java did: increase the level of abstraction and Make It Easier To Do the Right Thing ™. (Automatic downloading of dependencies is a total gimmick, IMO, and it always irritates me when I see Maven heads touting this.)
Bo: I’ve always experienced it the other way around. If there is a good Ant file that just works I’m happy, but I’m always wary because I’ve seen some shockers. They can tend to make a lot of assumptions about the environment (Which I don’t see as often in Maven builds), or force you to put a lot together yourself (construct properties pointing to dependant jars, etc).
I don’t recall the last time I saw a shoddy Maven build, but if you can lend an example I’d be happy to take a look and think about what caused it to happen.
Maven’s bugginess has been drastically reduced through the release candidates and is getting very close to a 1.0 release. If you haven’t had a look recently, I’d encourage you to give it another try.
You’re right, Maven isn’t an Ant killer – it attacks project management from an enitrely different angle. I often fall into the mistake of making the comparison though as it is often made by others. Having said that, I haven’t had a need for ant in 12 months on my own projects other than to bootstrap Maven from scratch.
Dependency downloading is not exactly a gimmick, but I see your point. However Maven’s strength in this area is the total solution it provides for artifacts. Not only will it pull down other peoples dependencies, but help you manage, version and publish your own.
I’m firmly in the liking Maven camp.
Dependency grabbing is a first big win for me. We need a CJAN and Maven is bizarrely the first real thing that enough people use to make such a thing happen. Creating my own repository of jars would be a pain in the arse. I have been tempted at work to stop people hitting the iBiblio repository and only use an internal one if we decided to control what jars were legal to use.
I hate building things with Ant. I’ll type ‘ant’ and it will fall over. I’ll look and discover I have to edit build.properties and find jars for it, downloading from god knows where and finally get it all patched together so the Ant file will build.
Either that or I’m downloading lots of Jars in the distribution or getting them out of CVS. The CVS case seems to implicitly have the Hibernate problem. I get ‘commons-lang.jar’ and not ‘commons-lang-1.0.1.jar’. ie) The project hides the dependency version.
I have two major environments in which I use Maven as an admin. Work and OSJava. I’ve customised things increasingly in both places. The OSJava stuff has been customised a lot on the website side [due to Hani’s complaints actually] and no longer uses the Maven menu which I dislike. Having now found what I like there, I could dump Maven and create a global Ant system to replace it, but why bother. I’d only have to design the website and match the features I use.
The Work stuff is good, because it stops every developer there having to constantly hack Ant scripts. At an early point someone was doing lots of custom jelly things in the maven.xml, but I’m slowly weeding this out. My belief is that maven.xml should rarely exist. For the things that have a need to exist, I have created a work-plugin which effectively becomes the standard extra functionality. Mainly it lets me manage all of the companies build system a lot more easily than if there were a plethora of Ant scripts out there.
As you asked, my problems with Maven, and I’ve suffered with it since 0.1:
Dependencies of dependencies are not solved. Someone seems to have tried to fix this very early on as they used to have pom/ folders on the first Maven repo, but they were never filled. It seems quite simple and recursive a thing to do. JJAR was closer to this the day Maven was born than Maven seems to be. [JJAR was Geir Magnusson’s dependency handler that is in Jakarta Commons Sandbox and became obsolete and died when Maven emerged. It could be called from Ant and give people their dependency system].
No concept of dependencies having different needs. Ones that should be packaged for runtime in the dist, unit-test only ones, etc. Again, 0.1->0.4 used to have a comment saying it had to separate runtime and compile time ones. I think that came from Maven and not me. It seems to be an issue that has dropped out now so I have to do my own true property.
Changing website between rc1 and rc2. I like having a simple, easy to use documentation system. It’s not beautiful, but it’s better than what I’d create with the time I can devote. I’ve tweaked the colours a bit, made my own navigation.xml etc. However in rc2, people are raining on my parade with a changed site. I need to see if I can set some property to old.site=true, but I doubt it. This will keep me on rc1 indefinitely as I’m not suddenly changing my l&f at another project’s insistence.
Jelly. I’m okay with Jelly. Yes it’s a bit odd, but for basic needs, one language is much the same as another. The biggest problem with Jelly is that it’s not a very active project. I can deal with the brackets if must be, but Maven are right to get off of Jelly as they are the only real users I’m aware of.
Documentation. It’s better than it used to be, but not as good as it once was. Maven 0.4 or so had good docs. Pete Kazmier did some good work here, but as I think happens to a lot of documentors, found himself more and more involved in product development than product documentation. Then it got really bad. The site documented CVS HEAD and this was horribly out of touch with the latest stable release. Then it got better as the site and stable got closer to each other due to less releases. Now it seems quite unchanging. Things like Wiki’s can help here, but in Maven’s case, and many others, I think it merely adds to a greater confusion as there are more locations to find the information in. Unmanaged.
Arrogance. Maven advertising contain(s?)(ed?) a lot of arrogance. Take the automatic ‘Development Process’ which is put on the end of every navigation list. Hooking everyone up to claim they use Maven’s processes. The site should be very empty by default and require active turning on of things. It’s easy to add a line to add Javadoc report generation, it can be a pain to figure out how to hack it out. Make the default Maven site/functionality simpler.
Too late to keep going on. I should just blog this separately 🙂
I like maven and use it a lot these days, but some problems should be solved
multiple source folders:
————————
a must with xdoclet…
IDE integration:
—————-
I maintain a seperate build.xml for the things maven cannot do AND the things I want to left-click in the IDE (therefore I don’t care about jelly)
poor documentation
——————
better now, but still a mess: no wonder that newbies give up at a certain point – sooner or later people want to know how maven works: where is a exact description of the mechanism?
More helpful comments – thanks!
Henri:
– dependencies of dependencies (transitive dependencies)
This has been on the wishlist for a long time, and you’re right, is partially implemented. We’ll be doing this first thing after 1.0.
– web site changing: now there is a controversy! You might like to search the -dev archives to see what happened after that got committed. This was a big pain although I do like the new one a lot more myself. The original idea was to put it more in the users hands, but thta’s not quite how it turned out. Jason is working on this big time now for doing it right, but again post-1.0.
– dependency types
Several proposals of how to take care of this and some work being done on the 1.1 mainline.
– Documentation
I’ve started assigning myself all the doco bugs and am about to do a big review for the 1.0 release. Stay tuned.
– Arrogance. Never heard it phrased that way before 🙂 I see your point and its funny to some extent to have that as part of the project charter. I think this annoys a lot of people so I’ll take your comments into consideration.
If you blog separately, let me know!
anon:
most stuff was addressed in other comments except
– IDE integration: The mevenide project is ramping up quite a bit and we are looking to work closely with them to get this happening. I think this has a bright future.
Thanks for all the feedback – it’s giving some useful insights.
Feedback is here:
http://www.jroller.com/comments/lsd?anchor=maven
Because I am tired of people creating “something else” when with a little effort what we have could be great!
One of the complaints I have about maven is the quality of some of the plugins. Especially the XDoclet plugin, trying to get the bloody thing working is a big pain, but once you get it working (which involves getting putting the jars in the proper place, the last time I tried it the XDoclet plugin does not reference the files properly in ibiblio).
Anyway one of the contributions I have made to maven is the genapp for an web and EJB project.
The other bad part (not really sure who to assign the blame to, no one’s fault anyway) is getting the bloody thing working with cactus as well. This is a very big pain when I created the complex app template.
Some of the other plugins do not seem to make sense to me.
Why do we need both a jboss and appserver plugin? appserver should do both.
why do we need to have j2ee, when we have ejb, ear and war?
I would really like to see a nightly and an integration build of maven just like the eclipse project. And it would also be nice to have a uber-changes document that lists all the changes in all the plugins and maven.
Archimedas: yeah, I’ve lamented this forever too. Unfortunately some of it is too entrenched to change during an RC phase, but I’d like to reorganise all the artifact-like plugins and other such common plugins (like grouping the report ones, the appserver ones, etc).
One other thing I do not like about maven is that I find it difficult to switch an existing project that runs on ant to maven. Actually I am not even sure how to proceed, especially with more complex ant scripts.
What I would like is something that would take my existing ant script and convert it to maven.xml first. That maybe easily done with an XSL file (MAYBE). Perhaps a plugin where I would say.
maven ant:mavenxml -Dmaven.namespace=myproject
which would translate my ant targets to myproject:build for example.
(the default for maven.namespace would most likely be empty though I don’t think that would be a good idea either)
But lets say that facility does exist. That would be step one
The next thing I would do is
maven genapp -D????templatename????=doc
Which would generate an application template for documentation purposes only, no compile stuff.
After that is done, we would have another goal with some really weird magic going on called…
maven ant:analyze-mavenized which can do the following…
search for javac calls and check the source directories, and give the appropriate tasks or actually do them. Namely set the value of sourceDirectory in project.xml to whatever javac calls and remove it from analyze-mavenized (at least comment it out and shove in a
same with test goals somehow guess that it is test sources you are compiling and shove them into the unitTestSrcDirectory in the project.xml
also the clean target can be moved to maven if it is easily done.
like I said that would call for some magic and most likely not going to happen for 1.0, but I think the ant:mavenxml should still be there. I’ll post a feature request on that plugin if there isn’t one already.
But since ant:analyze-maven is going to be ridiculously complex to build, I would suggest at least a document on how to migrate from ant to maven which could start out with those two steps I outlined (which should be reduced to one if possible — call it ant:mavenize) and it should provide an xdoc to explain how to finish the move.
The xdoc would go on and explain how to find your source directories and set the value for source appropriately. How to set things up so all your builds go to target or some other value which you can set up on the project.properties file.
Which also reminds me, has there been thought on using XML instead of a properties file for the project.properties file? Its just a thought, especially looking at the stuff I wrote which looked quite hideous because of xdoclet.
BTW to whoever wants to have multiple source directories because of xdoclet, if you do a genapp there is a sample ejb project that uses xdoclet but not require multiple source projects on the maven level (it does do it on the eclipse plugin though).
Which reminds me, there should be better communication between maven plugin developers I think (maybe its there maybe it isn’t, I am not a forum scanner myself, but some of the plugins do not seem to be jiving with one another, maybe that’s why we have both j2ee and ear plugins.
As I consider Maven’s pros and cons vs. Ant 1.6’s, the dealbreaker for me is the concept of a POM. An abstract model of the project, separated from process, is a very powerful concept. Since the project data is separated out from the build process, it can be reused for other processes, such as software configuration management.
POMs enable easy aggregation and reporting on project data. For example, what are all the current versions of the projects, and how do those match up against tagged versions in our version control system? What does our dependency graph look like? Answering these questions is extremely important in an enterprise development environment, and a POM really enables that.
Now you could make the argument that you get the same thing from an Ant properties file; unfortunately, properties just aren’t rich enough syntactically for storing complex, interrelated data in a file format. You end up with outrageously long property names a la Log4j.
While XML is the wrong tool for scripting (ahem… Jelly), it’s a great tool for implementing a POM. And that, for me, is Maven’s biggest value above and beyond POA (Plain Old Ant).
So here’s some food for thought: what if someone wrote a POM task for Ant? Ant 1.6 + POM task + a revitalized JJAR/Ruper task. Now _that_ would be a real build tool.
One final thought in conjunction with my previous comment. I’d love to see the OS Java community standardize on a POM; I know there’s been some discussion in the Maven community in that regards. A standard POM has so many possibilities: a higher degree of compatibility between IDEs (NetBeans and Eclipse) on their project file formats, easier transitioning of build process from Ant (assuming a theoretical POM-intelligent Ant) to Maven or vice versa, easier setup of continuous integration tools (CruiseControl, Gump), etc.
Bah. Now that I’ve started thinking about the problem, I re-discover Ant’s task. Well, OK, so it seems an Ant buildfile could read a POM (unless I’m horribly misunderstanding XmlProperty). Groovy + Ant 1.6 + XmlProperty + a revitalized JJAR/Ruper would indeed be a pretty sweet setup.
But Ant-bies still need a robust task for accessing Maven-like repositories, and the Java build community would still benefit from a standardized POM. Especially given projects like Invicta (http://invicta.sourceforge.net/) which seem (to me) to duplicate Maven’s functionality. I don’t care if functionality is duplicated, as long as all the build tools can talk with each other (ie, via a standardized POM).
A few suggestions on plug-in documentation:
1) Remove the unnecessary “Maven” from the front of every plug-in.
2) Break them in to categories (as Brett suggested)
3) Have a hieararchical list that shows one-line summaries
of the goals for each plug-in on the plug-ins page (so you
can quickly find the right goal accross multiple plug-ins)
4) Clearly mark things that are (or should be!) deprecated to
cut down on the “Is it jar:jar, war:jar? web:war? war:dist?”
confusion.
5) Some how-to’s and examples would be nice
I think Maven is great in concept, but has several flaws:
1) jelly sucks.
2) too strict hierarchy of working folders
3) xdoclet does not work properly…
4) overwhealming functionality. Is it REALLY necessary???
5) Lack of good integration with IDEs. It seems there are some open source plugins for Eclipse out there, but still they are not as stable as ANT integration
6) Lack of documentation, specially compared with ANT
Anyway, I think it’s the best representative of the next generation of Open Source tools, but it still has to evolve, may be until the V2…
I’ve (re-)evaluated Maven for a few projects now, and every time, the result was negative. The reason? The hard migration path from existing ant-based projects to maven. There’s no “step-by-step” scenario possible (“First we do this with maven, and let everything else still be handled with ant. Then we’ll migrate this.” And so on.)
In terms of arrogance, having a response to a common question “Why You Cant Create Multiple Artifacts In One Project?” starting with “It’s just bad. Ok?” is pretty arrogant. And keeping the answer there for such a long period of time won’t be too good either.
I think if you just take that one line out it would make things easier. Also provide some information on how to migrate to use multiple projects, not sure how to do it easily and FAQable but providing some text that says it will be added would be good too.
http://wiki.codehaus.org/maven/WhyYouCantCreateMultipleArtifactsInOneProject
Maven needs use cases.
I ran across references to Maven about six months ago and tried to find out what it was. After spending an hour searching and reading, I gave up. For me the “it makes everything easier” description is meaningless.
There should be a set of use cases that justify the need for Maven and a description of how Maven meets those needs. I can’t afford to take the time to explore every new “cool tool” to see if it might be of use in my projects. I have to be selective and use cases could help guide that selection.
Further, once I decide a tool is good I have to get management approval – I imagine most developers have dealt with this issue at some time. That means I have to put together the use case justification for the new tool. If use cases already existed, including some I would not think of, it could make the approval process a lot easier. Even if I think it’s the “best tool ever” if I don’t get management approval, I don’t get to use it.
Documentation woes will be solved. Take a look at my book (a work in progress) at http://www.milindparikh.com.
I really like Maven; despite the Jelly Quirk. Maven is NOT an ant replacement. It is, truly, a project comprehension tool.
– No need for development status meetings every week on a Friday afternoon for three hours.
– Drastically reduced time for code reviews
– Coming soon… A drastically improved Project Status Page for each project. The upper management does not need to come to me for status of each and every project. Just look it up on the published website which is updated every hour.
I’ve been using Maven for a while now, and I think it is getting too ambitious on what it should do. It was supposed to simplify project configuration and it seems to me it is complicating it. Transitive dependencies could be acheived with multiple project inheritance (a hack I use myself). But the main issue I see is the maintenance of public maven repositories. I think Ivy is getting closer to Maven’s first intent. Configuration handling in Ivy is superior to Maven’s. But anyway keep up the good work!
I hate Maven because Maven-driven projects are always broken. I don’t think I have ever downloaded a maven project and got it to build very easily. Either there is some crazy dependency missing, it cant download the right jars, the proxying properties don’t work behind a firewall, or…etc. Some of these problems may have been fixed since I have used it or of course, some of these problems are a result of a poorly constructed Maven project. The way I see it is that Maven is just a huge opportunity for developers to screw up the build process. For instance, has anybody besides people working on the project, been able to build an milestone release of Apache Geronimo? Its a nightmare.
I particularly hate the fact that jar dependencies are downloaded separately from the source. Yes, sometimes people just want to see the source, but I have seen projects out there that provide a …-nodeps-…zip version of the source, which is a better solution. The truth is, I can’t see how it buys you anything. It doesn’t save any bandwidth because you are probably going to have to download the jars anyway through the Maven process. It simply adds more time and complications to the build process.
Brett, sorry if this post reads like a rant, but I have had endless frustration with Maven.
I wanted to like Maven…
We use it here at work, and we ported our ant build system over to it because we thought that it solved many of the problems we had with ANT…
Sounded good, but it’s been, and continues to be, a thorn in my side.
I won’t go into the problems that aren’t maven’s fault… bad source code factoring and grouping, etc.
I will, however, give an opinion of my most hated maven feature, as at our workplace this was one of the primary selling points: jar dependency and versioning management.
This sounds great, and in truth I like the idea that you can tie your build to the versions of jar files you use, and have the build always go out and get the proper version for you. You always know what you have, and you always have the right ones, right?
Well, yes… if you can find them. The problem is that the mirrors change versions periodically, forcing you to either refactor your code to fit the version now available (which isn’t a good option if the jar file disappears say during a release cycle), or forcing you to get a copy of the one you want and put it on a local repository somewhere.
For example:
I set up new boxes frequently, for automation, etc… These boxes have an empty local maven repository when they are built (unlike the official build machines, which have the jars from all the previous builds). Supposedly, maven will go get all the jars for me, but on at least a dozen occasions, like today, one or more of the jar files isn’t available any more. If I didn’t have a local copy that I can use to put in our ever-growing in-house repository, I’d have to handle the available jar file or find the copy somewhere else.
Sometimes, like today, the version of a jar goes back in time to a previous build (like antlr-2.7.5 to antlr-2.7.4). What’s up with that?
That’s pretty lame, if you ask me, and it happens again and again.
To sum it up…
Too often our builds fail NOT because of a code change or some other real problem, but because maven is doing the “right” thing.
I think that this explains some of the problems people are having with open source projects that use maven as the build tool. Because the project is built on a machine already having a jar file in .maven, the project team thinks it works, but once it’s released to the public the dependencies don’t get resolved.
I love and hate Maven. I love it for lifecycle goals and dependency management. Call me old school but I hate it for the simple reason that when I do autocompletion on the linux shell for project I have to type x or p to get the right file. I would have given them different names.
(1) Maven forces me to structure my project in a way that I don’t like and, more important, that I do not consider optimal for development and maintenance.
(2) I was first confronted with maven when I tried to understand the building of an OS project. That’s when I started hating it, because it took me days to find out. There is no simple introduction. I didn’t want to buy a philosophy, I just needed a different packing of a jar. Had it been ant, this would have been a matter of minutes.
I wonder if someone did a cost benefit analysis of Maven. I see a lot of benefits, but not necessarily the cost.
I started a blog entry discussing this here.
http://trajano.blogspot.com/2006/03/costbenefit-analysis-of-switching-from.html
From Michael Lipp’s comments, he already has an idea how to package things and switching to maven from the way they know how is a bit of grief.
Formation’s comment seems to stem that ibiblio is not really the most stable source for dependent jars. Personally, I think a local repository should be used and not rely too much on the ibiblio repositories which is what he did. Remote repositories such as ibiblio is great when you are in RUP’s elaboration phase and trying to find out what is best, but during construction phase it should be a stable set and not much change to the dependent jars unless there is a bug to be fixed.