Right now, we have the rest of the code set so that SCALA_HOME takes precedence over scala.version. I would personally prefer to leave it this way, since FSC is unavailable when we use the Maven artifacts.
Whatever we decide, I think Scala.version should reflect the same precedence that `compile` does (the current version in trunk/ does not). Daniel On Sun, Apr 4, 2010 at 5:54 PM, Alex Boisvert <[email protected]>wrote: > On Sun, Apr 4, 2010 at 3:47 PM, Alex Boisvert <[email protected] > >wrote: > > > On Sun, Apr 4, 2010 at 2:46 PM, Daniel Spiewak <[email protected] > >wrote: > > > >> I seem to be having problems resolving the JavaTestFilter class in trunk > >> when running Buildr against a Specs-using Scala project. It worked fine > >> before I merged the latest from trunk into my fork, and there are no > >> problems under JRuby (just MRI). Has anyone else seen/seeing this or is > >> it > >> an issue which is peculiar to my system? > >> > > > > It appears to be another issue related to RJB bootstrap, not that you've > > removed Java.load from version_str. I think RJB blacklists the package > > "scala." since it's not found the first time it looks for it. > > > > I think we're trying to be too smart with the Scala detection, > considering > > the limitations of RJB. > > > > Having spent too much time on this already, I think we should remove > > Scala.version_str entirely (well, for backward compatibility we could > > redirect to Scala.version) and Scala.version should: > > > > 1) check if SCALA_HOME is defined, if so use the value from > > library.properties, > > > > 2) check if build setting 'scala.version' is defined, if so return it > > > > 3) or else, return Scala.DEFAULT_VERSION > > > > This would fix another issue where Scala.version could potentially return > a > > version different from the one pointed by SCALA_HOME. > > > > What do you think? > > > > Sorry... changed my mind. > > I think it should be: > > 1) check if build setting 'scala.version' is defined, if so return it. > > 2) check if SCALA_HOME is defined, if so use the value from > library.properties, > > 3) or else, return Scala.DEFAULT_VERSION > > I think the project's 'scala.version' should override SCALA_HOME. As an > optimization, if both 'scala.home' and SCALA_HOME agree on the version, we > could use artifacts from SCALA_HOME instead of downloading them from a > remote repo. > > alex >
