Started a new job and everyone here is using Maven to manage their projects… Anyone had any experience with it?
Kev
I haven’t, but I’ve evaluated it a couple of times (and that’s why I’ve never used it). Initial impressions were:
- it’s another apache project that re-invents several wheels and provides an incomplete implementation of them
- …and, just like many apache projects, “could be really good if they ever finished it”
- …and, just like many apache projects, seems to have only two USP’s: one: it uses XML extensively albeit naively (monolithic XML files), two: it is sort-of integrated with all the other apache projects
EDIT: this sounds more negative than intended. I’m not saying it’s bad, just that I could find nothing to recommend it over what other options are out there. I’m a bit depressed that this happens often with Apache projects. Even more so that so many apache projects look really good, and then the longer you use them the more you discover how crap they truly are. The last 3 major Apache projects I used (not small things!) had bugs so severe they were almost unusable, or were missing some of their own major features. Basic stuff didn’t work :(.
To quote from their site:
"use of a central repository of JARs. Maven comes with a mechanism that your project’s clients can use to download any JARs required for building your project from a central JAR repository much like Perl’s CPAN. "
- Um. Guys. Why replace webstart with a CPAN-clone, given that CPAN was pretty crap? (although, when it first came out, a lot better than the alternative!)
" The biggest bang for you buck right now is the generation of your site documentation."
- what? That’s all? Well, why not just use one of the dozen or so open-source project-mgmt apps that run on top of wiki’s and integrate:
- project schedules
- documentation
- ANT builds
- public website
- team-organization tools (discussion groups, mailing lists, etc)
…which all come with much nicer GUI’s and usually more features too. And, with a Wiki (or similar) underlying them, powerful and easy to extend.
So, each time I evaluated it, I came away with the feeling:
“It’s re-inventing stuff that’s already done just as well or better elsewhere, yet it’s less mature, and it’s ignoring the opportunity to integrate pre-existing components that could make it into something unique and wonderful. In the apache world, if a project you could have integrated with isn’t part of jakarta, then it doesn’t exist as far as you’re concerned…”
I only ever tried the examples, went through the quickstart guides / whatever intro stuff I could see / etc. I’d love to know what it’s like on a group of major projects, but I doubt it could make up for the massive drop in functionality if I ever moved away from Vesta ;D so I doubt it will ever grab me now.
I’m using it daily.
It’s ok, has some nice features, can generate a lot of useless things.
Needs a lot of infrastructure! Documentation is poor.
Zillions of plugins, goals and properties and conventions.
Very powerful but complex.
I like it and I dislike it.
Interaction with IDEs is quite good.
I use Ant to build compile classes, build Jar files, generate Javadoc, copy source code etc. Are there any benefits of using Maven for such simple tasks? I don’t need a central repository for Jar files. 
Yeah, I’ve used it quite a bit - it’s fantastic. I see no value in writing Ant scripts these days - Maven takes care of all that for you. I won’t start any new J2EE application without using Maven; it saves a lot of time and hassle, and allows you a lot of flexibility for the future.
My only complaints:
[]Sun libraries aren’t in the repository, due to licencing restrictions - a bit of a pain.
[]From my experience the devs aren’t super-proactive in handling bug reports.
[*]Doesn’t currently come bundled with Eclipse.
But to counter these complaints:
[]It’s really, really easy to set up a local repository with anything extra you want.
[]It’s really stable - most of my bug reports were either RFEs or cosmetic problems.
[*]Meh. A little more work required to get things integrated.
Edit: Technically, I guess I’m a Maven contributor… I fixed their timezone-calculating JavaScript functions. ;D
[quote]I use Ant to build compile classes, build Jar files, generate Javadoc, copy source code etc. Are there any benefits of using Maven for such simple tasks? I don’t need a central repository for Jar files.
[/quote]
If you’ve already got the scripts working, probably not. Although I’m not sure why you’re using Ant either - doesn’t your IDE provide all that?
From my experience, Maven is best used on a project with multiple developers, that needs some kind of public presence (either for third-party developers or for project managers) - although I’ve even found it useful on a solo project where the deliverable was all that mattered. YMMV and all that.
[quote]I won’t start any new J2EE application without using Maven; it saves a lot of time and hassle, and allows you a lot of flexibility for the future.
[/quote]
Exactly what/why/where does it save all this time and hassle?
Your followup post suggests it’s the “maintaining the public image of the project” part. Is that the main selling point for you?
[quote]Exactly what/why/where does it save all this time and hassle?
[/quote]
For me, Maven provides three things:
The automatic download and installation of dependent libraries means trivial setup of new build environments, it severely cuts down on versioning problems between developers, and means all versioning information is in one place (ever spent time trying to work out what version of Xerces you’re running?)
The pre-written goals are almost certain to function properly (as many other people have already tested them), they sometimes make adding new technology to a project trivial (as someone has already written goals to handle it), and stop me from having to write yet another Ant script with yet another collection of filesets and classpaths that potentially need to be updated every time a resource moves or changes format, or a class changes package.
Automatic site documentation means I can very easily keep my Javadoc up-to-date, provides a complete web-browsable, hyperlinked, syntax-highlighted copy of the source code, and provides easy-to-read task lists, warnings lists etc.
[quote]Your followup post suggests it’s the “maintaining the public image of the project” part. Is that the main selling point for you?
[/quote]
Depending on the project, company, and management style, project documentation may be utterly ignored, occasionally viewed, or rabidly sought after. It’s very handy that Maven can produce a huge amount of information, with very little effort.
Having been here a week now I’m starting to understand what you’re getting at. Across this company you get all sorts of IDEs (read VIM in some cases), different operating systems and plenty of machines.
Maven allows them to have a common format describing their projects and be able to morph it into what ever they need when they need it with minimal hassle.
Seems pretty neat so far…
Kev
How is this better than just pointing to the libraries using a classpath? I don’t need automatic downloading of Jar files from the net.
My IDE can probably build and sign Jar files, create JavaDoc etc. but it’s nice to have an Ant task that does all that for you in one run.
No, I haven’t - because I have a decent build system to start off with, that ensures that’s never ever a problem.
What you describe in this paragraph is the bread and butter of any build system, so assuming you are actually using one, it’s not an issue.
Could you explain a bit more about what these are?
Javadoc does the docs in one line.
Showsrc does the syntax highlighting in one URL.
If you have a decent issue-tracking system then it will do much more powerful management of task lists. I wouldn’t say Bugzilla is excellent, but it’s decent and free and presumably a lot more widely tested than Maven?
This is what I meant when I said everything seems (to me as an outsider) to be done better already elsewhere. You seem to be painting a picture of the whole being more than the sum of the parts, but…I’ve never had difficulty integrating any of the things mentioned so far, except for build system + issue-tracking system (I would really like a trivial config option so that each build would automatically produce a list of the bugs/rfes/etc that were fixed in that build, and even output a summary a la Sun’s JVM “bugs fixed in this JVM” list).
I’m pretty sure I can do that myself, I just need to write two scripts which I think I know everything I need for … but, obviously, not having to do it at all would be rather nice!
Yet…Maven doesn’t transparently plug in to other build systems, does it? And does it interface trivially with existing issue-trackers? I mean, there’s no way I would sacrifice my build system (which kicks the pants of everything else that’s free) nor would I move away from Bugzilla to anything free (there’s a lot of non-free issue trackers that are considerably better than BZ, some as cheap as just a thousand dollars or so, but in the free world BZ gets all the dev time and is much more mature than the rest…).
The key difference in this respect seems to be the number of developers/platforms/IDEs/etc… that are in use. Maven is really a framework to support everything… does seem to be fairly useful although interestingly here (at work) the opinion seems to be split aswell.
Kev
Opinion seems split everywhere… ;D
[quote]How is this better than just pointing to the libraries using a classpath?
[/quote]
Well, if you want to upgrade a library, for instance, I guess you go to the library’s website, download it, put it in the right place, possibly change your CLASSPATH env var or your build script to point to it etc. Then you tell all your fellow developers to do the same (unless you’ve been a little more clever and have the libraries in version control).
In Maven you just change the version number in your project.xml.
exactly: any decent build tool automates this to a two-step process (obtain files, alter build script).
What happens when the new version breaks existing code? Does it just mean that people’s projects stop building, and they have to go and find out by hand which library was updated?
Can they “downgrade” the library just for their project?
(this is the kind of functionality built-in to a standard build tool, so I’m just checking if Maven keeps up :))
[quote]What you describe in this paragraph is the bread and butter of any build system, so assuming you are actually using one, it’s not an issue.
[/quote]
Well, yes. But how many people here are using build systems that keep track of things like library versions for them? I think that’s pretty advanced, really, considering most people here are probably either using Ant or their IDE.
[quote][Pre-written goals] Could you explain a bit more about what these are?
[/quote]
Well, if you’re setting up an Ant script to compile source code, you need to write a javac task, setting the right srcdir, destdir, classpath etc, working out the right dependencies etc. Maven’s already done this for you - you just type “maven java:compile”.
Equally, goals have been written for all kinds of things. Want to add a new tool to your build system? Try typing "maven " and see what happens. More often than not, I’ve found everything already in place. Naturally, if you ask Maven to start working with a new tool, it’ll go and acquire all the required libraries itself.
If it’s a third-party tool, download the Maven plugin, chuck it in the plugins directory and start using it. If that tool’s libraries aren’t in the central Maven repository, you might need to add an entry in your project.properties to point to the project’s own repository.
[quote]Javadoc does the docs in one line.
[/quote]
Yes, but you need to type that line, and create a task for it, yadda yadda yadda. Try typing “maven javadoc”.
[quote]Showsrc does the syntax highlighting in one URL.
[/quote]
Non-hyperlinked, requires network access, and works on a per-file, per-request basis? That’s no comparison. I think you’re being difficult! 
Isn’t this a little more useful?
[quote]If you have a decent issue-tracking system then it will do much more powerful management of task lists. I wouldn’t say Bugzilla is excellent, but it’s decent and free and presumably a lot more widely tested than Maven?
[/quote]
Well, of couse you use Bugzilla as your issue tracking system - Maven is a build tool, it won’t replace that. However, Bugzilla won’t go through all your code finding all the “TODO” comments and creating a readable list of them for the website. Maven will.
[quote]I’ve never had difficulty integrating any of the things mentioned so far
[/quote]
Sure, but it’s probably easier to just download Maven-1.0.2.exe and double click it. 
[quote]I mean, there’s no way I would sacrifice my build system
[/quote]
Well, if you say you’ll never sacrifice your build system, it seems a bit unnecessary to give that as a reason not to use a different build system…
Point taken. But…ignorance of what else is available isn’t a justification for adopting something inferior (if it’s inferior…I’m talking theoretically here; jury’s still out w.r.t. Maven as far as I’m concerned)
Ah! See what you mean now. Sorry, just a difference in terminology. I should have guessed that myself.
Right. This is one of my long-standing bones of contention with the Apache/Jakarta projects. if this worked perfectly, it would be very useful and rather wonderful. It would, at the same time, be a holy pain in the arse for everyone involved because Apache’s projects are not and never will be a global standard; however, it’s perfectly possible that Sun would (again?) cherry pick bits to clone into java. They might even simply deal with the Maven people directly and work together to migrate it into Sun’s “official” tehcnologies (e.g. elevated to the status of webstart).
However…the reality is that Apache projects keep trying to do this “we’re Microsoft, we’ll integrate everything in our own unique proprietary way, and make it ‘open’ and pretend to ourselves that tthat’s all it takes for everyone in the world to adopt it”, but…in reality, what happens is that adoption is mediocre. on the surface there are “thousands of plugins”, but when you use them in anger you find that they’re all the “minimal implementation theoretically possible” and are often completely useless: what they “integrate” is the stuff you could have done yourself in 5 minutes with a shell script without any of the apache stuff, yet what they completely sidestep is the complex, high-level integration of some feature or config that you desperately wanted to avoid having to do for yourself.
.
I have been bitten by this on more than one occasion. For an example, look at Log4J. They tout the huge number of plugins as a major reason for using it over alternatives; when you start trying to find plugins, you quickly shatter the illusion and discover that most of them do the same thing as each other and are toy projects. There’s a few (literally: just a handful) of plugins that are genuinely and widely useful, but really they’re just stuff that you assumed was going to be part of the core distribution anyway.
Once. Once in your entire life. Is that so hard?
Point taken; it’s been sufficient for my needs so I’ve never bothered to try finding a better one. It happened to be the only easy-to-use and feature rich one I knew off the top of my head, and I wanted to give real examples to make the point.
But…this is surely the raison d’etre of Maven: to integrate the disparate parts of the project tools suite?
Instead of saying “let’s integrate the best of breed” they’re saying “let’s re-invent our own proprietary inferior clones of the existing tools, because then the work of integration is trivial”. Which is silly: they’re just shoving the “hard” task elsewhere (instead of integrating complex software, they’re going to have to write complex software).
FYI I find that deeply unimpressive. I could write code to do that myself in … about 10 minutes, that could be used on any project (iterating through plain text files looking for lines with TODO on them is trivial, and then you pump it to XML, and can style and re-style it into HTML to your heart’s content)
But…this http://jtidy.sourceforge.net/junit-report.html I find extremely useful. Although, what we’re really looking at here is (or should be) a plugin for Junit (which has a plugin architecture to do this sort of thing), which could be used by anyone without using Maven.
Sorry. I meant “never sacrifice the features provided by my existing build system”. I.e. I’ve got a good (maybe not best-of-breed, but certainly high quality, high performance, feature-rich, well maintained) build system - why downgrade to something that is a lame clone without most of the useful features?
This is what I don’t understand about apache projects: the insistence on using/re-inventing their own wheels all the time, when they could actually do the whole world a favour by re-using far far superior systems and integrating them. ???
[quote]What happens when the new version breaks existing code? Does it just mean that people’s projects stop building, and they have to go and find out by hand which library was updated?
Can they “downgrade” the library just for their project?
[/quote]
Oh, blimey - no reason to do that. All library versions are separate, you’ll never stomp on someone else’s project. Otherwise how would you ever compile up an old version of the project from version control?
We have recently started to work with Maven at work, and I see a lot of both positive and negative in that. Previously we really didn’t use any build tool other than what’s provided by Eclipse, CVS and a few plugins. So for us it was quite necessary to use something.
At home on my private game dev, I still use IntelliJ and ANT and see no reason to change that. I have an ANT script-template that I use. I basically drop all src, libs and resource in a separate folder, change ANT script with the name of project and web dest of where I want to upload the webstartable stuff and that is pretty much it. A dbl-click and ANT will build, create java docs, make jar, obfuscate, backup src to zip-file, package deployment jar for offline/e-mail deployment, create webstart files and upload to web host (or just a subset of this), all with version number. Work overhead is very small, and I have a powerful enough build system.
At work we previously had a few e-mails every week saying “Add foo.jar and bar.jar to your classpath”. Everybody had to do this update, and half of the time you forget it until your build don’t work. With Maven, you will just add the necessary jar to our local repository, and specify that in a xml-file and commit to repository. When the rest of the team-mates updates anything dependent on that project or that project itself, the new/updated jar is automatically downloaded by maven!
With cruise-ctrl installed you will also be sent an e-mail stating that you messed up a build if you for example forgot to commit in a crucial file to CVS out of all the 50 you made updates to. Also typical thing that happened weekly before.
We also have several different modules that a customer may or may not want to have/buy. Maven helps with the management of all these different modules.
Other build tools can probably do the above, but maven seems to do it very well, even though I agree with some of the complaint mentioned previousley in thread.
These are just the key benefits for each approach for me. I would use ANT for one man small project, since it means no extra work for me and Maven for bigger projects with multiple coders, since it removes some of the problems that it involves.
Hope this was of some use
Howabout sharing that script? We’ll have an area on JGF soon where you can share short chunks of source code around on a “you can do anything you like with this” license.
Sounds like what I was asking about, yet cfmdobbie said it didn’t do that…?
Well…if you still use CVS then to be honest it’s your own fault :P. Really, CVS is barely halfway to being an SCM, if that.
Of course, with vesta, when you check in it builds the code immediately (or vice versa), so you have to try quite hard to deliberately check in without compiling (or do a “partial check-in” which means “work in progress, but I’d like to checkpoint it temporarily”
Yup. Testimonials with detailed post-mortem descriptions are the best way IMHO of evaluating any new dev tool.