Posts Tagged ‘maven’
I won’t be wrong if I say clojure’s official build tool is Leiningen (http://github.com/technomancy/leiningen/) . Leiningen uses maven for dependency management. Maven has always been an controversial topic in Java word. Some people like it and some don’t.
We all know this joke
“Q: What’s the difference between Ant and Maven? A: The creator of Ant has apologized.”
To be fair, I have worked with Maven in only project and it was not a good experience. I am still not sure whether it is fault of Maven or the way we used. I want to understand. I love Clojure and I am going to be using Clojure for sometime. I want to make sure we learn from what has been done before and make correct choice esp for a build tool. If Maven is bad, then we should re think about Leiningen using Maven.
The idea for this blog is not be give a conclusion, rather to gather information to make a better choice.
“If you’re on a project that is similar to a single Apache project (a single distributable with a single set of unit tests) then you’ve hit Maven’s sweet spot.”
“Using Maven, instead of having a lib folder per project, you have a “local repository” (just a bunch of files in a particular directory structure) instead where your jars can be used by multiple projects. Each project defines it’s dependencies in a sensible declarative way and Maven sorts out the classpath for compiling the code, running the tests, or even packaging everything into a self contained executable jar with all dependencies. “
“Having the project’s dependencies specified in the Maven way means that you only need this information in one place.”
“Maven is like a set of sensibly written Ant targets which can be used with hardly any effort as long as you use the standard Maven directory structure. Things like compiling, running the unit tests and creating a war. It also provides a suprisingly large number of more advanced build related things, like running code coverage or pmd reports – also very easy to use without having to write a load of stuff.”
“build lifecycle, standard project layout”
“reusable plugins, repositories”
“Dependencies are downloaded automatically”
“There is some benefit from Metcalf effects. If everybody assumes that everybody else is using maven, the tools get written with that assumption, the IDEs support it and so forth.”
“For something that is supposed to save me time, I sure as hell am wasting a shit load of time on making it do what I want and watching it do what it does (or not), and fixing the way it works. “
“Few people around me dare to touch pom files. It’s like magic and I hate magicians myself. When it doesn’t work they look at me to fix it.”
“Maven is not capable of remembering the history of what you did and what has changed since the last time you ran it so like any bureaucrat it basically does maximum damage to compensate for its ignorance.”
“Maven is brittle as hell. Few people on your project will understand how to modify a pom file. So they do what they always do, which is copy paste bits and pieces that are known to more or less do what is needed elsewhere. The result is maven hell.”
” You’ll be stuck with no longer needed dependencies, plugins that nobody has a clue about, redundant profiles for phases that are never executed, half broken profiles for stuff that is actually needed, random test failures.”
“When one team is producing a number of artifacts, you find yourself needing to work around the Maven structure, often with resorting to “Pom Inheritence”. You have to do ugly things like maven installs before hand.”
“If you need to do anything more complex than the standard build, then you start to obfuscate the build process. Strange things like different processes running under different profiles (whether or not the build is running on a build server or not) can be very confusing for lots of people.”
“Maven adds more complexity to your development environment as you rely on either a public artefact server, or need to set up an internal one. Whilst this seems simple, it is yet another environmental factor that affects how you develop, and its external nature adds variability to projects that often cause false negative build failures.”
“We’re building a very large and complex product consisting of over 75 projects which in all have over 400 pom files! Maven just can’t handle it. When it doesn’t try to download dependencies and plugins we didn’t specify, it fails to clean the build directories before building, or confuses SNAPSHOT with release build numbers! Not to mention the lack of backward compatibility from one Maven version to another, from one plugin version to another. Plugin Hell!”
“Total productivity loss counts in man-months to clean up the mess every time.”
“Maven is broken and wrong if it behaves differently on my laptop at the office and at home. Maven is broken and wrong if it requires an internet connection to delete a directory.”
“Maven’s broken dependency management is also a gaping security hole, since it is currently impossible in Maven to determine where artifacts originally came from and whether or not they were tampered with. Artifacts are automatically checksummed when they are uploaded to a repository, and Maven automatically verifies that checksum when it downloads the artifact, but Maven implicitly trusts the checksum on the repository it downloaded the artifact from.”
“Maven advocates claim their tool embraces the principle of Convention Over Configuration; Maven advocates are liars. The only convention Maven supports is: compile, run unit tests, package .jar file. Getting Maven to do anything else requires configuring the conventions.”
If I missed out something, let me know I will update.
– Siva Jagadeesan
PS: If your code is not deployed it does not matter whether it is written in clojure or cobol … it is a waste.