buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Spiewak <djspie...@gmail.com>
Subject Re: NoClassDefFoundError : org/apache/buildr/JavaTestFilter in trunk
Date Sun, 04 Apr 2010 23:09:44 GMT
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 <djspiewak@gmail.com> 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 <alex.boisvert@gmail.com>wrote:
>
>> On Sun, Apr 4, 2010 at 3:47 PM, Alex Boisvert <alex.boisvert@gmail.com
>> >wrote:
>>
>> > On Sun, Apr 4, 2010 at 2:46 PM, Daniel Spiewak <djspiewak@gmail.com
>> >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
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message