Nice. I think it's much more sane now. I'll take care of updating the docs later.
thanks, alex On Sun, Apr 4, 2010 at 4:26 PM, Daniel Spiewak <[email protected]> wrote: > Alright, it's up. We probably should make some changes to the shell code > to > allow use of Maven-downloaded artifacts (right now it requires SCALA_HOME), > but that's another project. > > Daniel > > On Sun, Apr 4, 2010 at 6:22 PM, Daniel Spiewak <[email protected]> > wrote: > > > Already done. :-) I'm just doing a little testing before I commit. > > > > Daniel > > > > > > On Sun, Apr 4, 2010 at 6:20 PM, Alex Boisvert <[email protected] > >wrote: > > > >> My thinking exactly. You want me to do the legwork? > >> > >> alex > >> > >> On Sun, Apr 4, 2010 at 4:09 PM, Daniel Spiewak <[email protected]> > >> wrote: > >> > >> > 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 > >> > >> > >> > > > >> > > > >> > > >> > > > > >
