Done in r930748. We still try the internal API first, but if that fails, we look in the scala-library.jar file and parse the library.properties file. If that fails, *then* we return nil.
Daniel On Sun, Mar 21, 2010 at 6:09 PM, Alex Boisvert <[email protected]>wrote: > 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 >
