Of course, there is a rather serious downside to giving SCALA_HOME precedence: we lose a lot of configurability. The user would have to actually *unset* ENV['SCALA_HOME'] if they really wanted to have scala.version become the dominant, and that seems hacky. Since most users aren't going to set scala.version unless they really need it, maybe we * should* go with it as the primary.
Daniel On Sun, Apr 4, 2010 at 6:03 PM, Daniel Spiewak <[email protected]> wrote: > 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 >> > >
