If the author doesn't want me to use it, why does he have 50 links to it in the text of his article?
To show that he is familiar with it and isn't just shooting from the hip.
Maven builds are an infinite cycle of despair
31–40 of 51 posts
Re: Maven builds are an infinite cycle of despair
#32Seems like the typical reaction seen over and over. People love to hate maven. It always goes like this: 1) try maven but don't bother to RTFM 2) run away with your hair on fire and back to cave-man tools like Make, Rake & Ant 3) ignore dependency management 4) re-invent the build script for _EVERY_ project you start. 5) ??? 6) profit!!! You only ever hear rants like this from people who don't spend the time to learn…
Rant or not you hit the jackpot.
Most Maven users are "forced" to use it when they join a company or a project; they did not pick up Maven and learn it on their own time.
Re: Maven builds are an infinite cycle of despair
#33Earlier quoted context omitted.
buildr combines the advantages of maven with the advantages of being built on top of rake and scales to managing multiple projects. Groovy's Grails build system and Scala's sbt also both look good to me, although I have not yet taken the time to try them. The only reason I can think of why systems like buildr aren't more popular than maven is that most Java developers appear too unwilling to learn a separate programm…
I'm sorry to disagree with you but some people would rather invest their time to learn how to use Maven more effectively than to learn another programming language _and_ a new build system altogether. Breadth vs Depth I suppose.
Check out this page: http://buildr.apache.org/quick_start.html. I will paste the most relevant text below.
"No knowledge of Ruby is assumed. Buildr is designed to be a very intuitive, very easy-to-use tool. You can create buildfiles which describe incredibly intricate projects, write custom tasks which do things far beyond Ant, and still never need to pick up more than a smattering of Ruby syntax."
Also, learning a new programming language isn't exactly a waste of time. When I learned Ruby it made me a far better Java programmer, for instance.
Re: Maven builds are an infinite cycle of despair
#34I wish the author had been more specific about how Maven had failed him, especially regarding the "convoluted hackery" he mentions with the pom file...
So far, I haven't had much trouble with Maven. I've only done fairly straightforward web programming, with Spring, Struts 2, and Hibernate. It was a hassle to get it all set up, but I blame Spring for that, not Maven. The conventions seem to work very well, since you can just follow a standard directory structure.
I've found it particularly easy to use mvn war:war to create a war file, which is why I wish the author had elaborated a bit on why he needed to "reconfigure the conventions".
I have no argument with the author's preference for rake (and rails, for that matter), which is a far more pleasant environment than maven, spring, struts 2 (or something else), and hibernate, but of all this, Maven (I'm talking about Maven 2 here) was by far the most pleasant part of the stack for me.
One last thing - I promise I'm not being glib, feigning misunderstanding where I actually disagree. I'm pretty sure the author is a good programmer who has a legitimate gripe, and all I've done is basic CRUD programming with the stack I mentioned... but I definitely would like to hear some details.
Re: Maven builds are an infinite cycle of despair
#35> Automatically downloading unresolved dependencies makes your build process nondeterministic! This. You need to be able to check in your build tools, and use them as they were to precisely repeat any build you've ever done, or you're risking bit rot. Ant is sort of painful but it works for this. And if I want my dependencies to be preinstalled rather than checked in and bundled, I'd rather use yum so the rest of the…
This. You need to be able to check in your build tools, and use them as they were to precisely repeat any build you've ever done, or you're risking bit rot. It's not non-deterministic if your dependencies include an explicit version. You should not be using unversioned -SNAPSHOT dependencies for release builds. And if I want my dependencies to be preinstalled rather than checked in and bundled, I'd rather use yum so…
I think you're right that in principle one can make a maven build deterministic, but in practice I have yet to see it done. Of course, that could just be a statement about the crowd I hang out with, but I think there are more fundamental problems. Wouldn't you have to specify explicit version numbers for not only your immediate dependencies, but also all transitive dependencies? Not that that's necessarily a bad thing in itself--regardless of what build system you use, if you want a reproducible build, one way or another you have to specify particular versions of all dependencies. But if you have to provide a configuration file that explicitly lists all direct and indirect dependencies, then what's the point of all the sophisticated transitive dependency management functionality we hear so much about?
Also, you didn't address the gp's complaint that the build tool will spontaneously update not only the project dependencies, but also itself. Some maven plugin developer out there can release a new version, and a project that compiled fine yesterday suddenly won't compile anymore. I'm sure there's a way to force it to use particular versions of the plugins as well, but by the time you explicitly list every transitive dependency and every plugin used in every phase of the lifecycle, you've got a really big configuration file, especially for a tool whose motto is "convention over configuration." Not to mention that if you accidentally forget to specify a version number for one of these potentially dozens of packages, maven will happily default to using the latest version, which makes your build secretly nondeterministic.
Re: Maven builds are an infinite cycle of despair
#36Seems like the typical reaction seen over and over. People love to hate maven. It always goes like this: 1) try maven but don't bother to RTFM 2) run away with your hair on fire and back to cave-man tools like Make, Rake & Ant 3) ignore dependency management 4) re-invent the build script for _EVERY_ project you start. 5) ??? 6) profit!!! You only ever hear rants like this from people who don't spend the time to learn…
It sounds like the author has had quite a bit of experience with Maven and most likely has RTFM.
Sounds much more like a rant to me. The complaint about the war file size is a prime example. There are several quick / easy ways to analyze this and fix it / force it to generate exactly what you want. None of that is particularly advanced mvn black magic.
It sounds like he chose to just give up on the tool, spend a lot of time ranting about it on a blog, and go back to what he was familiar with.
Re: Maven builds are an infinite cycle of despair
#37Earlier quoted context omitted.
This. You need to be able to check in your build tools, and use them as they were to precisely repeat any build you've ever done, or you're risking bit rot. It's not non-deterministic if your dependencies include an explicit version. You should not be using unversioned -SNAPSHOT dependencies for release builds. And if I want my dependencies to be preinstalled rather than checked in and bundled, I'd rather use yum so…
I think you're right that in principle one can make a maven build deterministic, but in practice I have yet to see it done. Of course, that could just be a statement about the crowd I hang out with, but I think there are more fundamental problems. Wouldn't you have to specify explicit version numbers for not only your immediate dependencies, but also all transitive dependencies? Not that that's necessarily a bad thin…
What you're missing here is sort of described in the RTFM. There are a couple very good, free books on maven that describe this, but in essence:
1) You absolutely should have your own local repository (e.g. Archiva). 2) You should use and tags to force all projects to have the same versions o all deps and plugins. 3) Don't even try using snapshots unless you know what you are doing.
Re: Maven builds are an infinite cycle of despair
#38I'm interested if anyone at HN has good things to say about Maven. I've only scratched the surface of it, but my initial impressions have been: * slow (even with -o to stop it downloading the internet every time) * incredibly verbose, in both configuration and output during builds * inflexible (but I've not really looked into plugins or advanced configuration) * opaque and thinly documented even for basic needs I did…
I've found maven to be useful. It standardizes the layout for the majority of java based projects. It also lets me deal with dependencies in a decent manner. Maven should not be downloading dependencies on every build unless you are using SNAPSHOT versions. There is a free book available: http://www.sonatype.com/products/maven/documentation/book-de...
Thanks very much for linking to the book - that will be very useful.
(I know Maven doesn't actually redownload everything each time, but it does seem to do something on the internet every time I build without -o; and even with -o, it still seems slow to get going. Might be project-specific / PEBCAK error though.)
Re: Maven builds are an infinite cycle of despair
#39Earlier quoted context omitted.
I'm sorry to disagree with you but some people would rather invest their time to learn how to use Maven more effectively than to learn another programming language _and_ a new build system altogether. Breadth vs Depth I suppose.
Check out this page: http://buildr.apache.org/quick_start.html . I will paste the most relevant text below. "No knowledge of Ruby is assumed. Buildr is designed to be a very intuitive, very easy-to-use tool. You can create buildfiles which describe incredibly intricate projects, write custom tasks which do things far beyond Ant, and still never need to pick up more than a smattering of Ruby syntax." Also, learning a…
I think it depends. Is learning a new programming language a waste of time compare to getting better with the current programming language that you knew already?
While I'm learning Ruby, it did not make me a better Java programmer. I still suck at Java programming.
Reading books like Code Complete, Pragmatic Programmer, Clean Code, and reading Zen of Python (import this) help me to become a better programmer; but learning Python does not help me to become a better developer. Reading better code (other people's or projects's) do make me know more.
I finally understand what does it mean with the phrase "no matter what they tell you, it's always a people problem.". Languages have nothing to do with it.
Re: Maven builds are an infinite cycle of despair
#40I am doing solo part time development (1 day/week) on a very large orphaned enterprise system. The builds are done using maven. The build takes about 15 minutes because maven is going off to various sites looking for no longer supported versions. I removed the dependencies; not much improvement. I tried mvn -o and the build dropped to 3 minutes. But war file was broken in mysterious ways. The currently irreducible st…
I'm about to do a hobby project and Maven seems to be a good choice for me. In fact, I'm about to learn how to generate project related websites using Maven.