4 ms·

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

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/org.eclipse.egit.github.core/2.1.5 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.

eropple 13y ago
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.