You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@buildr.apache.org by Alex Boisvert <al...@gmail.com> on 2010/03/21 15:20:24 UTC
Re: svn commit: r925716 - /buildr/trunk/lib/buildr/scala/compiler.rb
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, <dj...@apache.org> 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
>
>
>
Re: svn commit: r925716 - /buildr/trunk/lib/buildr/scala/compiler.rb
Posted by 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
>
Re: svn commit: r925716 - /buildr/trunk/lib/buildr/scala/compiler.rb
Posted by Alex Boisvert <al...@gmail.com>.
On Sun, Mar 21, 2010 at 11:55 AM, Daniel Spiewak <dj...@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
Re: svn commit: r925716 - /buildr/trunk/lib/buildr/scala/compiler.rb
Posted by Daniel Spiewak <dj...@gmail.com>.
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.
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.
Daniel
On Sun, Mar 21, 2010 at 9:52 AM, Daniel Spiewak <dj...@gmail.com> wrote:
> 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" <al...@gmail.com>
> 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, <dj...@apache.org> 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
>>>
>>>
>>>
>>>
Re: svn commit: r925716 - /buildr/trunk/lib/buildr/scala/compiler.rb
Posted by Daniel Spiewak <dj...@gmail.com>.
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" <al...@gmail.com>
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, <dj...@apache.org> 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
>>
>>
>>