This blog posting is mostly spot on.
I guess I need to try out Rake, but the idea of using Ruby to solve a Java problem, seems like a bad idea too. Ant, with all its warts, is still my preference after all these years.
My favorite quote from that posting:
"Maven builds are an infinite cycle of despair that will slowly drag you into the deepest, darkest pits of hell (where Maven itself was forged)."
I couldn't agree more with everything the author said. I've been there. If you are using Maven to do builds, you should have your head checked (or even better, commit privileges revoked).
Friday, January 1, 2010
Which build tool to use...
Subscribe to:
Post Comments (Atom)
13 comments:
While I can´t say that maven is perfect I think it helps big companies in standardizing their builds. The maven way is really most times what you need. Of course you could do some things better by hand but this leads to projects that are not very compatible.
Besides standardization I really like the dependency management. It allows you to combine different projects without much effort. I still remember the days before maven when it was vitually impossible to combine several projects like cxf, spring and hibernate into a running application. Something always didn´t work like it should and you had no idea how to fix it. Nowadays the big and important projects can be combined without much problems. Of course maven tends to draw more dependencies than you absolutely need but this is mainly because many open source developers rather use another lib than write 10 lines of code. What really sucks is if projects are moved to new group ids or are simply configured crappy (like many sun jars). They really make your life hard. But even sun is getting better at it ;-)
Your tolerance for crap must be greater than mine. =)
Personally, I have no problems with dependency management using the system I use.
You should have a look at Buildr!
You get Rake, Ant, the few good parts of Maven, support for multiple languages and much more!
http://buildr.apache.org
Posting here since Kent doesn't allow comments.
I agree with most of the warts the original poster sees with Maven: configuration is painful, builds are slow, etc.
But Maven got a ton of stuff right: tiny core, rich plugin infrastructure. Writing a plugin is dirt simple. Super fast development when conventions are followed (ie: rake). Dependency management kicks Ant's butt (no more committing .jar files to scm).
I'm split. I have issues with both Ant and Maven. Maybe buildr or something else would be better.
I've said this before, but I'll say it again. Committing jar files to svn is a good thing. I'm not sure who started that belief that it isn't, but they should be kicked in the nuts.
The problem with maven repos is that they simply aren't safe. It seems that pretty much anyone can upload jar files there. I've had several of my projects get jar files uploaded to the repos by who knows who. Other than md5/sha signatures against the files that I distribute (do you check all your jar files?), who knows what those jar files contain. I've been tempted for years to illustrate this insanity by putting a corrupt jar up there.
Second, if someone decides to remove a jar from the repo or Maven decides to change their repo format (which they did between m1 and m2), your build is broken. That is horrible. 10 years from now, you really want to be able to check your project out from svn *at any revision* and just know it will build.
If you have a ton of projects in svn and you don't want to have to check in 50 jar files into each project, you can have a central project (at work we call it KinkAlexandria) which is just a repo of jar files. There is a simple jar.properties which is a mapping of name of the jar file to a version. ie: foo.jar=foo-1.1.jar. Each project just ant imports that properties file. This system works great. Then each of our projects just references those jar files. I've been doing this for 3+ years now and we haven't had a single problem with this solution. I know exactly what versions of jar files go into my ear files and where. There is no magic and there is no confusion.
There is really one thing that could go wrong in a maven repo. Someone could overwrite an existing release version of a jar. Using the right server software and access policies this can be avoided and I am quite sure that the central repo has both.
Storing the jars in a subversion repo is not necessary in my opinion as each jar should only be written once.
I was curious how you solved the dependency problem but I did not really understand what you are doing with the property files. Wouldn´t it suffice to store the files in a directory hierarchy like maven does? (e.g. /groupId/artifactId/version/artifactId-version.jar).
I also have another question. How do you deploy your own lib jars? Do you also store them in your repo or do you always build from source?
Btw. another build tool some people really like is ivy. I have not yet used it myself though.
Greetings
Christian
If I get some time, I'll write up a nice long blog posting explaining how I do builds at Kink. Suffice it to say, it works great for us and we use nothing more than a relatively simple ant build file and svn.
Committing jar files to svn is a good thing.
I disagree; it's not that black-and-white. Every solution has its drawbacks and benefits. I prefer means of dependency management other than committing jars. Source control is for source. jars are just an intermediate representation of Java code, a convenience. Do you also commit C libraries?
Anyway, sounds like you've got a homegrown solution that does what you want. Right on.
Maven provides a solution, too, if you host your own repository you control exactly what's in there. I host a small static repository with a few artifacts that are not in other repositories, but Nexus (a caching repository server) looks pretty straightforward too. Using something like Nexus, you need only manage specific jars... most of the time the ones you pull down just work. And you can probably tell Nexus to hold on to disallow deletions or whatever.
Your jar.properties file is your implementation of metadata about libraries. That's good. Maven has that too, and "mvn site" uses the metadata to generate dependency graphs and a report on licenses used by your project(s).
As for Maven repository safety, that sounds like an issue with mvnrepository.com.
Again, I agree that Maven has warts. But dependency management ain't one of them.
Nexus is no different than checking in files into svn. It is just another repo. The adage that svn is only for source is just silly. Where did you come up with that rule from? Do you only check in your original photoshop files and not your jpegs? Yes, if I had a need to check in static libraries, I would prefer to do that then make up inane rules about what goes into a repo and what doesn't.
As for reports, I just don't see the need. How often do you really look at those reports? My dependency graphs are really simple and if they are really that complex, then you are doing it wrong. You have failed the KISS test.
Oh about mvnrepository.com. It has nothing to do with mvnrepository.com. Let me be a bit more clear.
I'm one of the core developers of subethasmtp. None of us core developers uploaded the jar file into the maven central repository, nor did we authorize it. That means that anyone can upload files into the central repo. That is inherently unsafe.
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/subethamail/
"I guess I need to try out Rake, but the idea of using Ruby to solve a Java problem, seems like a bad idea too. Ant, with all its warts, is still my preference after all these years."
well XML isn't java, so Ant is using XML to solve a Java problem. I still don't understand how people are so tolerant of writing scripts in XML.
Gradle, Buildr, or Rake + Antwrap gem. Use a real language! You get magical things like conditionals, loops, variables, debugging. You can sort of do these things in ant, but god it it awkward.
Yea, I agree... XML is a pretty bad way to describe a build file. I'm not advocating for ant, I'm just saying that it works and is a better solution than Maven. =)
I will spend some time soon on some of the other tools and see how they work.
Also check out gradle.
Maven is an abomination. It is horribly costly, also, as I keep having to replace monitors that I punch in anger.
The fact that it is nigh on impossible to do any reasonably complex builds without including the ant plugin (or something similar) or custom coding makes it obvious you should just skip the middleman and use something reasonable.
ant is far from ideal, but you can make it do what you want to do and once you've built an infrastructure with it, you can define your builds in a very simple manner that is much more understandable than the equivalent pom.xml. With maven, it feels like you basically have to trick it in to doing what you want.
And yes, there is nothing wrong with checking in jars. It works supremely well and you don't end up with things magically "upgrading" on you when you weren't expecting it.
And please don't tell me I don't understand maven or haven't learned it well enough to love it. Maven junkies have been using that argument for years and have not realized that if smart people (not me) have been trying and failing to work with maven in non-trivial projects without wanting to put out their eyes, their may be something fundamentally flawed with their system.
Post a Comment