Rubygems and Python packages are source packages. When you used the package management tools in those languages, these packages are downloaded to somewhere in your path and used within the code you are writing.
In fact in Rubygems, you can point to a Ruby git repository (like github) and have dependency management happen from there - no necessity for a centralized repository (like maven.org). This is how you share a ruby gem - http://guides.rubygems.org/publishing/#sharing_source_code . I can now specify in my Gemfile to pull a particular branch/tag/version of the gem directly from revision control.
The same thing happens with SBT or leiningen, except that they are JARs. I believe this comes from using maven as the backend. Therefore, either you need to setup a local repository or publish to Sonatype or some other place. This is how you share your scala code - http://www.scala-sbt.org/0.13.1-SNAPSHOT/docs/Detailed-Topic... . Remember, publishing means packaging into a JAR. If you were too lazy to package your code into a jar and publish it ... well, then it's cumbersome to work directly from the repo.
I really, really wish scala/clojure would enable the ability to work directly with source as packages - the big, big reason why it's not is the maven backend.
Most open source Java lib/framework that publish their JARs to the central Maven repository also publish their Source code and JavaDoc JARs as well. This is where I applaud the Java OSS community.
> In fact in Rubygems, you can point to a Ruby git repository (like github) and have dependency management happen from there - no necessity for a centralized repository (like maven.org).
That's a feature of Bundler, not Rubygems.
> The same thing happens with SBT or leiningen, except that they are JARs. I believe this comes from using maven as the backend. Therefore, either you need to setup a local repository or publish to Sonatype or some other place.
I don't follow. I mean, you don't need to setup a local repository anymore than you need to setup a local Rubygems repository.
It's got a number of JAR dependencies, followed by project references to projects on the local filesystem as well as Github, neither of which are JARs.
In fact, because I don't have much clue how to distribute my own libs on maven.org, I don't bother. If you want to use it, just drop the URI into your build.sbt and away you go.
Is this not what you're looking for?
If you want to create a JAR (say for deployment), and you're not working with a Play application, and you don't want to publish the JAR to a repository, that's cool too. Just run `package`, or use the sbt-assembly plugin. Just takes a couple seconds.
SBT is basically Rake + Bundler + RVM + Guard + RDoc all in one. I'm not aware of anything that those do that SBT can't. It's pretty easy to pick up as well. People complain about it, but I've personally invested a lot less time learning SBT than I have in those tools and feel like I'm probably as proficient at this point.
@ssmoot - this is extremely interesting. Thanks for pointing out RootProject.
After doing that, are you able to use them just as seamlessly as declaring it in libraryDependencies. For example, "sbt assembly", etc. work just as fine ?
The reason my code is SBT 0.13.x specific is just because .sbt file syntax was robustified in 0.13.x to cover most cases you'd previously need a Build.scala for.
You can do the same thing easily in 0.12.x, it just requires you do it in a Scala class that extends sbt.Build instead. In fact, that's what my code was a few days ago. I only just ported it to the new SBT 0.13.x syntax since the old syntax continued to work. We'd been using 0.13.x for awhile, I just hadn't got around to porting the build from being spread across build.sbt and project/Build.scala to consolidating to just the build.sbt.
The docs for SBT are actually really thorough, but to me at least, a bit hard to get into. I blame the theme at http://scala-sbt.org and the fact that there's no obvious "from basics to mastery" guide. The website feels more like a manual. Going deeper than you might want pretty quickly, but before you've got the breadth of it down. If that makes any sense?
That said, if you end up having to work with SBT for your day-job, you end up picking everything up pretty quickly once you're forced to. It's a lot more consistent than anything on the Ruby side. You may have a few syntaxes to choose from to add a libraryDependency for example (single, Seq, special operator), but the mechanics are all the same and directly exposed to you. You're building a definition for the build, not actually performing work, so as long as that dependency sequence ends up with the graph it needs you'll get the result you need. There's not a lot of magic to it. Despite peoples complaints about the operators (which honestly, there's only two or three you'll run into regularly, and it's not black magic, just look them up or Command+B in IntelliJ to see what they do).
I'm not sure I understand why this is a problem. SBT, leiningen, maven and pretty much every other build tool on the JVM supports publishing source jars. I think SBT even does it by default. Nearly all of the open source projects I have worked with on the JVM publish their source jars (Grails used to not but even they do now).
Are you running in to a lot of projects that don't publish their sources?
In fact in Rubygems, you can point to a Ruby git repository (like github) and have dependency management happen from there - no necessity for a centralized repository (like maven.org). This is how you share a ruby gem - http://guides.rubygems.org/publishing/#sharing_source_code . I can now specify in my Gemfile to pull a particular branch/tag/version of the gem directly from revision control.
The same thing happens with SBT or leiningen, except that they are JARs. I believe this comes from using maven as the backend. Therefore, either you need to setup a local repository or publish to Sonatype or some other place. This is how you share your scala code - http://www.scala-sbt.org/0.13.1-SNAPSHOT/docs/Detailed-Topic... . Remember, publishing means packaging into a JAR. If you were too lazy to package your code into a jar and publish it ... well, then it's cumbersome to work directly from the repo.
I really, really wish scala/clojure would enable the ability to work directly with source as packages - the big, big reason why it's not is the maven backend.