On Sun, Mar 21, 2010 at 11:55 AM, Daniel Spiewak <[email protected]>wrote:
> Actually, upon further reflection, it occurs to me that we could move the > Java.load to the *call-site* for compatible_28? This would defer loading > until the compiler is actually invoked, at which point we will need to have > Java loaded regardless. > I was going to suggest that. > The main downside to this approach is we're stuck with an unreliable > Scala.version method. It'll work for detecting 2.8 as we need it, but > anyone calling Scala.version early in their buildfile will be in for a > surprise. > I see two more approaches, 1) Give up detection of Scala and require buildfile to specify it. My experience so far is that projects usually require a specific version due to the many incompatibilities between Scala versions (and artifacts compiled for these different versions). For projects that support multiple versions, it would be easy to have a user-defined conditional that picks the version. And if SCALA_HOME doesn't point to a compatible version, we try to fail as early as possible. (We could go even further and stop using SCALA_HOME completely; I'm not sure I have a rational justification for using SCALA_HOME anymore since we can now pick up the artifacts from public repos). 2) Detect the Scala version by reading "library.properties" in scala-library.jar (via ruby code) instead of calling scala.util.Properties.versionString via bytecode. This would avoid using Java.load early. alex
