[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ivy-user
Subject:    Re: Ivy and Scala : how to best represent platform/toolset/runtime difference?
From:       Geoff Clitheroe <g.clitheroe () gmail ! com>
Date:       2011-07-07 2:19:34
Message-ID: CAO2rXRZRvkwgxOg=ao0E=LNYOa-LQUfe=u0h0fqzZ0p4qjYZWw () mail ! gmail ! com
[Download RAW message or body]

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.Gervais@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
>

[prev in list] [next in list] [prev in thread] [next in thread]