Hi, sorry if you have seen this already but have you tried SBT - the simple build tool for Scala? It uses Ivy under the hood to manage deps. I saw a few demos and it looked so nice I wanted to use it for pure Java projects.
https://github.com/harrah/xsbt/wiki http://stackoverflow.com/questions/2888031/changing-scala-version-in-existing-sbt-project Cheers, Geoff On Thu, Jul 7, 2011 at 6:27 AM, Mathieu Gervais (IDEAS) <mathieu.gerv...@morganstanley.com> wrote: > Hi, > > Are there any best practices around how one would use Ivy to represent > various versions of the scala runtime? > Scala is still evolving, and many scala libraries are not compatible with > e.g. 2.8 and 2.9. > > We have an internal ivy repository and we are wondering how we can best > represent this situation? > The goal is that I should get the dependancies that work only with my given > target runtime. > > Among ideas we have: > a)-don't make ivy deal with it, and explicitly by having the scala version > coded in the module name , e.g. lift-2.8.x. . > e.g. theoritical example: > module=lift-scala-2.8x revision=2.1 # lift 2.1 works only with scala > 2.8.x > module=lift-scala-2.8x revision=2.3 # lift 2.3 works with scala 2.8 > and 2.9 (but possibly the artifacts installed are different, after all these > are completely different modules) > module=lift-scala-2.9x revision=2.3 > module=lift-scala-2.9x revision=2.4 # lift 2.4 works with scala 2.9 > only > > Then you use something like > > <dependency name="lift-${SCALA_VERSION}" rev="2.3" conf="runtime" /> > > That's OK, but we feel it leads to many modules for no good reason while > also making it a pain to represent that a particular version binary > artifacts work with multiple scala versions. We end up with duplicate > installs in our internal repo etc. > > > b) use revision, e.g. module=lift revision=2.1-scala-2.8x > but that will cause issues for conflict resolution etc. so we think this > is a no go... > > c) use ivy confs, which would look something like: > > <dependency name="lift" rev="2.3" conf="runtime->runtime-${SCALA_VERSION}" > /> > > > Then if scala 2.10 is released and it turns out that lift 2.3 is binary > compatible with it, we just add this bit to our ivy repo: > > <conf name="runtime-scala2.10" visibility="public" > extends="runtime-scala2.9" description="Runtime for scala 2.10 (same as > 2.9)"/> > > > d) any other approaches?!?! > > In a/b/c, upgrading scala versions is easy: update SCALA_VERSION and resolve > again. We could even have that automatically defined based on which version > of scala itself I depend on. > > We are leaning towards option c) > > In a sense, we will have the same problem with the upcoming java7/8 > (certainly _some_ libraries will not be compatible with java7 and/or 8). > What's the best way to represent that? > > Looking forward to hear any suggestions. > > Thanks! > > -mathieu >
