Re: svn commit: r925716 - /buildr/trunk/lib/buildr/scala/compiler.rb

[Daniel Spiewak <dj...@gmail.com>]

Done in r930748.  We still try the internal API first, but if that fails, we
look in the scala-library.jar file and parse the library.properties file.
If that fails, *then* we return nil.

Daniel

On Sun, Mar 21, 2010 at 6:09 PM, Alex Boisvert <al...@gmail.com>wrote:

> On Sun, Mar 21, 2010 at 11:55 AM, Daniel Spiewak <djspiewak@gmail.com
> >wrote:
>
> > Actually, upon further reflection, it occurs to me that we could move the
> > Java.load to the *call-site* for compatible_28?  This would defer loading
> > until the compiler is actually invoked, at which point we will need to
> have
> > Java loaded regardless.
> >
>
> I was going to suggest that.
>
>
> > The main downside to this approach is we're stuck with an unreliable
> > Scala.version method.  It'll work for detecting 2.8 as we need it, but
> > anyone calling Scala.version early in their buildfile will be in for a
> > surprise.
> >
>
> I see two more approaches,
>
> 1) Give up detection of Scala and require buildfile to specify it.  My
> experience so far is that projects usually require a specific version due
> to
> the many incompatibilities between Scala versions (and artifacts compiled
> for these different versions).    For projects that support multiple
> versions, it would be easy to have a user-defined conditional that picks
> the
> version.  And if SCALA_HOME doesn't point to a compatible version, we try
> to
> fail as early as possible.  (We could go even further and stop using
> SCALA_HOME completely;  I'm not sure I have a rational justification for
> using SCALA_HOME anymore since we can now pick up the artifacts from public
> repos).
>
> 2) Detect the Scala version by reading "library.properties" in
> scala-library.jar (via ruby code) instead of calling
> scala.util.Properties.versionString via bytecode.  This would avoid using
> Java.load early.
>
> alex
>