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:22:04 GMT
Already done.  :-)  I'm just doing a little testing before I commit.

Daniel

On Sun, Apr 4, 2010 at 6:20 PM, Alex Boisvert <alex.boisvert@gmail.com>wrote:

> My thinking exactly.   You want me to do the legwork?
>
> alex
>
> On Sun, Apr 4, 2010 at 4:09 PM, Daniel Spiewak <djspiewak@gmail.com>
> 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 <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