If this is still
current<http://docs.codehaus.org/display/MAVENUSER/Scala+and+Maven>
the
Maven users are embedding the Scala version in the module version.
So module="lift" revision="2.8.0-realversionmajor.minor" or similar.
Not saying that Ivy should do the same, just sharing what others are
thinking.
Also -- would the branch attribute be a good use of this?
I believe you could specify branch="2.8" in a module's ivy.xml, and by
default it would resolve dependencies from that same branch. (and publish
its artifacts for that branch)
On Wed, Jul 6, 2011 at 11: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
>
