Scala 2.8.0 final
scala-lang.org
scala-lang.org
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'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?
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?
resources for learning maven, classpaths, autoboxing/primitives, all that stuff. HTH
However, the lack of API and ABI compatibility is a really big failure. I can't believe that they're shipping what is supposed to be stable software and we can't rely on our code to continue running, much less building.
We had to do a fair bit of work to fix our projects' 2.8 compatibility issues, and it's causing us all sorts of grief in terms of having to do lock-step upgrades of all libraries from 2.7 to 2.8.
They've put a hell of a lot of work into making everything as compatible as possible with 2.7. At some point you need to say, enough is enough, we're going to upgrade out and people will have to make minor changes to their source code to get the new features. They had 7 release candidates, so they've made a commitment to quality and given people time to upgrade leisurely.
... or Perl5 for that matter. Python has continuously broken backwards compatibility in their APIs between releases and that has allowed it to shed much technical debt.
It's annoying for developers, but it's better for the language and the ecosystem to keep evolving. Scala is taking the correct route here.
s/annoying/_expensive_/
but it's better for the language and the ecosystem to keep evolving.
Of course it's good for things to evolve. But you're painting a false dichotomy here.
Scala is taking the correct route here.
In the short-term? Just once? That may be true due to just how broken some things were.
In the long term? It's a very expensive thing to be breaking everyone's code and binaries.
Is that a real question or were you just setting up your false dichotomy via some well-placed rhetoric?
Where everything is shit because of backwards compatibility?
Oh, so that's why Java is so bad? Because it has some stagnant corners in which they're maintaining backwards compatibility? That's silly.
Backwards compatibility isn't holding back Java the language, or even Java the VM. Bad design decisions and an almost knee-jerk opposition to any forward progress holds Java back. You don't have to break compatibility to implement closures, you just have to herd cats until you can get people to agree on a proposal and implement it.
They've put a hell of a lot of work into making everything as compatible as possible with 2.7
But it's not actually compatible. And it may not be again in the future. And it's really easy to introduce binary incompatibility due to the implementation of traits.
If you look at other production programming environments, from C# to Objective-C, the maintainers bend over backwards to maintain binary and API compatibility across releases because it's bloody expensive to upgrade everything in lock-step, force all your customers to upgrade, wait for all your vendors to upgrade, and move the entire ecosystem to a new version in one gigantic step.
At some point you need to say, enough is enough, we're going to upgrade out and people will have to make minor changes to their source code to get the new features. They had 7 release candidates, so they've made a commitment to quality and given people time to upgrade leisurely.
Upgrade leisurely? To a release-candidate quality language release? Are you joking? Even if we wanted to upgrade to an RC release (and we didn't!), we'd had to wait for the libraries we depend on to be updated too (and wait for time to block development while we upgrade all internal components in lock-step).
I'd only add two things; firstly, I got the impression at Scala Days and from mailing list discussions that there was a little bit of a feeling that 2.8 was the last chance to fix some design choices that the designers didn't like. That Scala is big enough and well used enough now that they're not going to get away with the same behaviour for 2.9 or 3.0 and that there will be a lot more concern for compatibility in future. Whether it happens remains to be seen I suppose.
Secondly (although you might disagree with this), there are no glaring problems with 2.7 so there's no need to rush to upgrade to 2.8, there shouldn't really be a problem with waiting 3-6 months for your dependent components to release (stable) 2.8 versions. I think that we're lucky that we don't depend on many external libraries so we'll be upgrading pretty soon, but it wouldn't be the end of the world if we had to wait a few months.
Alternatively, if someone knows a better community that could field this question, I'd really appreciate being pointed in that direction. One thing I've not really grokked about Scala is where to go to ask such things!
The scala-user mailing list (http://listes.epfl.ch/doc_en.cgi?liste=scala-user) is the best place to ask (and get answers for) newbie Scala questions. Using the "scala" tag on StackOverflow also produces good results.
I recall there being a few missteps w/ earlier releases. Actors in 2.7.4 didn't seem to be thoroughly vetted.
http://codemonkeyism.com/scala-unfit-development/#comment-30...
In fact I am about to take a leave from university and found a startup to do commercial Scala support. I am taking some of the key Scala developers with me.