Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I googled for an answer to your problem and found this: http://www.scala-lang.org/node/1305.

The link basically recommends that you learn Java first :). For better or for worse, Scala relies a ton on Java, and no one has created Scala-specific tools to simplify some of these things you can already do with existing Java tools.

If you want to create a self-contained jar, the following URL has people discussing how to do this with SBT and Maven: http://www.scala-lang.org/node/6750. I wouldn't wish the curse of Maven on anyone, let alone someone who hasn't been force-fed it by the Java community for a while, so I'd recommend trying to learn sbt and then port the solution posted in the above link to your own sbt project. I really wish the solution were simpler, but Java tools have always focused more on server-side web deployment and have always been weaker in the area of client-side deployment.



* I wouldn't wish the curse of Maven on anyone, let alone someone who hasn't been force-fed it by the Java community for a while, so I'd recommend trying to learn sbt and then port the solution posted in the above link to your own sbt project. I really wish the solution were simpler, but Java tools have always focused more on server-side web deployment and have always been weaker in the area of client-side deployment.*

I've only ever used maven for Scala projects, but I've come across this sentiment a few times -- it always strikes me as odd, given that I have very few significant maven complaints.

It has all sorts of great tools for automatically fetching dependencies, and doing "the right thing" via some fairly simple conventions. It's really easy to wire up something like tomcat:run to run a war in-place -- or your own custom self-contained code.

I also really like being able to have a local maven repository where we can store our own build products (and declare dependencies against them); server software like Artifactory makes this very nice: http://www.jfrog.org/products.php

Maven isn't wonderful, but build tools never are. I don't understand why you would hate it. Why do you hate it?


I agree with most of what you said. I like the idea of Maven's dependency management and repositories. It's also nice to have a lot of plugins to take care of common build system use cases for you. I just happen to hate the rest of it. Fortunately, I can get the best of both worlds. Buildr, Gradle, Ivy, and sbt can all work with maven repositories. So I can take the best of Maven, a.k.a, the one and only really good thing about it, and use it with better build tools!

Now, as to why I hate maven, these several-year-old posts explain it better than I do.

http://labnotes.org/2007/05/03/buildr-or-when-ruby-is-faster...

http://labnotes.org/2007/04/18/introducing-buildr-or-how-we-...

And of course on StackOverflow Daniel Spiewak gives an excellent example of how Maven just falls flat.

http://stackoverflow.com/questions/1015525/why-use-buildr-in...

Really, it boils down to the fact that I believe that the philosophy of the Maven creators about build systems is fundamentally flawed. They say "when you want to script you know you're doing something wrong". I say, I'm a mature programmer, so give me a mature tool that enables me to get my job done.

Case in point. For a simple side project I was using JAXB to create an xsd from java classes. JAXB wanted me to maintain a flat text file listing all of the classes I wanted included in the xsd. I knew for a fact that every single java file inside a particular directory (recursively, of course) needed to be included in that xsd.

If I were using Maven, I would properly just resign myself to the fact that there is no JAXB Maven plugin to do what I want. I would therefore just manually update the file every time I added, deleted, or renamed a java class in this directory, which turned out to be very frequently during development. I certainly wouldn't feel it would be worth the herculean effort of writing a maven plugin and figuring out how to wire the file dependencies together so that the required tasks only run when needed.

Fortunately, I was using buildr, and 50 or so lines of scripting code later I had a perfectly efficient and automated solution to my problem. Now this was for a simple side project. Imagine a real product created by a real company. Do you really think that company won't ever have any custom build needs that go beyond the provided maven plugins?

Why waste your time with a limiting, clunky, slow, XML-based build system when you can use one that is designed better from the core and therefore easier to use, more flexible, more maintainable, and, best of all, faster because developers can afford to spend more time to wire things together efficiently?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: