Play 2.0+ is based on SBT as build system. SBT uses ivy and maven repos as source for dependency lookup. Maven repo's often show the SBT mantra form of a maven dependency. F.i. click on the sbt tab here http://mvnrepository.com/artifact/org.eclipse.mylyn.github/o...
If you don't want to add your dependency to a maven repo you can define a sub-project. SBT projects are aggregated recursively of other sbt projects.
My pet peeve is that SBT suffers from ungoogleable scalaz like operators like %% instead of %. And that the Scala IDE doesn't provide any help like code completion, marking compilation errors e.d. in creating your project/Build.scala
Those two facts make sbt a big hurdle in adoption I noticed.
Believe me, I've spent enough time with Play to know exactly how the build system does its thing with external dependencies.
The problem I'm referring to is that, for a long time at least (I know pre-2.1, maybe 2.1 as well), there was no way to aggregate non-Play projects--that is, ones that didn't have a conf directory and did have their own pom.xml or whatever--and use the recompiler. So if you were trying to build your project using an external Java/Scala domain object library that could be shared between projects and wanted it to hot-recompile while you're working (because I at least don't write every model class before I get going) you were in for a world of hurt.
My pet peeve is that SBT suffers from ungoogleable scalaz like operators like %% instead of %. And that the Scala IDE doesn't provide any help like code completion, marking compilation errors e.d. in creating your project/Build.scala Those two facts make sbt a big hurdle in adoption I noticed.