I agree. Adding the Java.load was actually a last resort (well,
almost last). The problem is that without this, I can't think of a
way to reliably determine the Scala version. Maybe we should run
'scalac -version' and parse the results?
For what it's worth, I think we're probably safe here because nothing
calls Scala.version until we get into the compile method (which has to
load Java anyway).
Daniel
On Mar 21, 2010, at 9:20 AM, "Alex Boisvert" <[email protected]>
wrote:
Hi Daniel,
Java runtime bootstraping can be tricky and I would advise against
placing
"Java.load" here. If a plugin/buildfile were to check
Scala.version (which
falls back to Scala.version_str), it would have the side-effect of
loading
the Java runtime and prevent other plugin or later buildfile
configuration
of the classpath.
I haven't looked into your compiler changes yet but I hope we can
move this
somewhere else safer.
alex
On Sat, Mar 20, 2010 at 7:43 PM, <[email protected]> wrote:
Author: djspiewak
Date: Sun Mar 21 02:43:53 2010
New Revision: 925716
URL: http://svn.apache.org/viewvc?rev=925716&view=rev
Log:
Fixed Scala version string retrieval
Modified:
buildr/trunk/lib/buildr/scala/compiler.rb
Modified: buildr/trunk/lib/buildr/scala/compiler.rb
URL:
http://svn.apache.org/viewvc/buildr/trunk/lib/buildr/scala/compiler.rb?rev=925716&r1=925715&r2=925716&view=diff
===
===
===
=====================================================================
--- buildr/trunk/lib/buildr/scala/compiler.rb (original)
+++ buildr/trunk/lib/buildr/scala/compiler.rb Sun Mar 21 02:43:53
2010
@@ -27,6 +27,7 @@ module Buildr::Scala
# standard library or nil if Scala is not available.
def version_str
begin
+ Java.load
# Scala version string normally looks like "version
2.7.3.final"
Java.scala.util.Properties.versionString.sub 'version ', ''
rescue
