ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mathieu Gervais (IDEAS)" <>
Subject Ivy and Scala : how to best represent platform/toolset/runtime difference?
Date Wed, 06 Jul 2011 18:27:02 GMT

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
       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

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

 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.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message