Best practices: Group/Org wide versions and/or config

15 views
Skip to first unread message

Lanny Ripple

unread,
Aug 7, 2013, 11:58:50 PM8/7/13
to simple-b...@googlegroups.com
Hi all,

In my org we're building several projects.  We probably should have made the mother of all multi-module projects but for various reasons we didn't and we aren't going to.  We're currently a maven shop moving toward sbt.  In maven we have a scala/pom.xml which gives us scala-maven-plugin, the version of scalaz we want to use and some other core libraries, and pulls in testing jars (specs2, scalacheck, etc) that we use on every project.  We also have a couple of poms that use scala/pom.xml as the parent.  In these poms we mostly do dependencyManagement sections.  These poms in turn are the parent of our differing projects.  We do this so that we're all using the same version of (e.g.) the json library we prefer.

I suspect doing something similar in sbt would involve creating plugins.  Mostly we're concerned about keeping jar versions straight but it would also be nice to always pull in testing dependencies and maybe a few other things as described above.  I've Google'd around and checked sbt docs and best practices but while I find a lot on how to be DRY in a multi-project build I don't find anything describing what seems to be a pretty common maven pattern around org-wide versions and common dependencies.  I'm hoping anyone that has experience or solutions for what I'm driving at will throw in their $0.02USD with advice or what they've found to be good practice.
Reply all
Reply to author
Forward
0 new messages