[scala] RunnableFuture not in my present

[Bill Venners-3]

Hi All,

Well I got the latest nightly 2.8 build to compile just fine with
ScalaTest 1.0, but when I run it, I get this stack trace:

[scalatest] java.lang.NoClassDefFoundError: java/util/concurrent/RunnableFuture
[scalatest] at java.lang.ClassLoader.defineClass1(Native Method)
[scalatest] at java.lang.ClassLoader.defineClass(ClassLoader.java:675)
[scalatest] at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
[scalatest] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
[scalatest] at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
[scalatest] at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
[scalatest] at java.security.AccessController.doPrivileged(Native Method)
[scalatest] at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
[scalatest] at java.lang.ClassLoader.loadClass(ClassLoader.java:316)
[scalatest] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:280)
[scalatest] at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
[scalatest] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
[scalatest] at
scala.actors.scheduler.ForkJoinScheduler.makeNewPool(ForkJoinScheduler.scala:33)
[scalatest] at
scala.actors.scheduler.ForkJoinScheduler.<init>(ForkJoinScheduler.scala:14)
[scalatest] at
scala.actors.scheduler.ForkJoinScheduler.<init>(ForkJoinScheduler.scala:25)
[scalatest] at
scala.actors.scheduler.ForkJoinScheduler.<init>(ForkJoinScheduler.scala:29)
[scalatest] at scala.actors.Scheduler$.makeNewScheduler(Scheduler.scala:28)
[scalatest] at
scala.actors.scheduler.DelegatingScheduler$class.impl(DelegatingScheduler.scala:24)
[scalatest] at scala.actors.Scheduler$.impl(Scheduler.scala:22)
[scalatest] at
scala.actors.scheduler.DelegatingScheduler$class.execute(DelegatingScheduler.scala:38)
[scalatest] at scala.actors.Scheduler$.execute(Scheduler.scala:22)
[scalatest] at scala.actors.Actor$class.start(Actor.scala:689)
[scalatest] at scala.actors.Actor$$anon$1.start(Actor.scala:108)
[scalatest] at scala.actors.Actor$.actor(Actor.scala:112)
[scalatest] at org.scalatest.DispatchReporter.<init>(DispatchReporter.scala:50)
[scalatest] at
org.scalatest.DispatchReporter.<init>(DispatchReporter.scala:179)
[scalatest] at
org.scalatest.tools.Runner$.getDispatchReporter(Runner.scala:1317)
[scalatest] at
org.scalatest.tools.Runner$.withClassLoaderAndDispatchReporter(Runner.scala:1561)
[scalatest] at
org.scalatest.tools.RunnerJFrame$RunnerThread.run(RunnerJFrame.scala:1359)

It looks like an actors dependency on Java 1.6 got into the nightly
build. Is there perhaps a version of this fork-join library ScalaTest
users still on 1.5 can include in the meantime that will resolve this
dependency?

Thanks.

Bill
----
Bill Venners
Artima, Inc.
http://www.artima.com

[Philipp Haller-2]

Hi Bill,

> It looks like an actors dependency on Java 1.6 got into the nightly
> build. Is there perhaps a version of this fork-join library ScalaTest
> users still on 1.5 can include in the meantime that will resolve this
> dependency?

Yes, that's the purpose of the new jvm5 branch:
https://lampsvn.epfl.ch/trac/scala/browser/scala/branches/jvm5

It will be used to built the scala-compiler and -library.jar for running
on 1.5.

There are some known issues with the 1.5 backport of the fork-join
library that I am going to address as soon as possible. Currently, for
best results run trunk on 1.6.

Cheers,
Philipp

[Lukas Rytz]

On Sat, Oct 10, 2009 at 12:05, Philipp Haller <philipp.haller@...> wrote:

Hi Bill,

> It looks like an actors dependency on Java 1.6 got into the nightly
> build. Is there perhaps a version of this fork-join library ScalaTest
> users still on 1.5 can include in the meantime that will resolve this
> dependency?

Yes, that's the purpose of the new jvm5 branch:
https://lampsvn.epfl.ch/trac/scala/browser/scala/branches/jvm5

It will be used to built the scala-compiler and -library.jar for running
on 1.5.

There are some known issues with the 1.5 backport of the fork-join
library that I am going to address as soon as possible. Currently, for
best results run trunk on 1.6.

Cheers,
Philipp

you can get nightly builds from the jvm5 branch on
http://www.scala-lang.org/node/212/distributions-five

cheers: lukas

[Josh Suereth]

Seems like we should include this in the maven repository as well, so users can select which version of the library they would like to use.  I can add a <classifer> tag to the pom that would say, e.g. "jvm5" or "optimise".  We could then have these nightlies available on the maven repository (and there for more easily available). 

Does anyone see any possible ramifications with this idea?  I know of a few areas I'd need to test out with the maven-scala-plugin.  I also know deploying the source artifacts into maven will be a no-go if we use classifiers.  Mark, anything SBT related?

- Josh

On Sat, Oct 10, 2009 at 7:08 AM, Lukas Rytz <lukas.rytz@...> wrote:

On Sat, Oct 10, 2009 at 12:05, Philipp Haller <philipp.haller@...> wrote:

Hi Bill,

> It looks like an actors dependency on Java 1.6 got into the nightly
> build. Is there perhaps a version of this fork-join library ScalaTest
> users still on 1.5 can include in the meantime that will resolve this
> dependency?

Yes, that's the purpose of the new jvm5 branch:
https://lampsvn.epfl.ch/trac/scala/browser/scala/branches/jvm5

It will be used to built the scala-compiler and -library.jar for running
on 1.5.

There are some known issues with the 1.5 backport of the fork-join
library that I am going to address as soon as possible. Currently, for
best results run trunk on 1.6.

Cheers,
Philipp

you can get nightly builds from the jvm5 branch on
http://www.scala-lang.org/node/212/distributions-five

cheers: lukas

[Kevin Wright-4]

On Sat, Oct 10, 2009 at 2:20 PM, Josh Suereth <joshua.suereth@...> wrote:

> Seems like we should include this in the maven repository as well, so users
> can select which version of the library they would like to use.  I can add a
> <classifer> tag to the pom that would say, e.g. "jvm5" or "optimise".  We
> could then have these nightlies available on the maven repository (and there
> for more easily available).
>
> Does anyone see any possible ramifications with this idea?  I know of a few
> areas I'd need to test out with the maven-scala-plugin.  I also know
> deploying the source artifacts into maven will be a no-go if we use
> classifiers.  Mark, anything SBT related?
>
> - Josh

+1

Java versions are the main example given in maven documentation for
the use of classifiers.

This also wouldn't interfere with the convention (as used by SBT) of
embedding Scala version numbers into other libraries.

> On Sat, Oct 10, 2009 at 7:08 AM, Lukas Rytz <lukas.rytz@...> wrote:
>>
>>
>> On Sat, Oct 10, 2009 at 12:05, Philipp Haller <philipp.haller@...>
>> wrote:
>>>
>>> Hi Bill,
>>>
>>> > It looks like an actors dependency on Java 1.6 got into the nightly
>>> > build. Is there perhaps a version of this fork-join library ScalaTest
>>> > users still on 1.5 can include in the meantime that will resolve this
>>> > dependency?
>>>
>>> Yes, that's the purpose of the new jvm5 branch:
>>> https://lampsvn.epfl.ch/trac/scala/browser/scala/branches/jvm5
>>>
>>> It will be used to built the scala-compiler and -library.jar for running
>>> on 1.5.
>>>
>>> There are some known issues with the 1.5 backport of the fork-join
>>> library that I am going to address as soon as possible. Currently, for
>>> best results run trunk on 1.6.
>>>
>>> Cheers,
>>> Philipp
>>>
>>
>>
>> you can get nightly builds from the jvm5 branch on
>> http://www.scala-lang.org/node/212/distributions-five
>>
>> cheers: lukas
>
>

[Mark Harrah]

On Saturday 10 October 2009, Kevin Wright wrote:
> On Sat, Oct 10, 2009 at 2:20 PM, Josh Suereth <joshua.suereth@...>
wrote:

> > Seems like we should include this in the maven repository as well, so
> > users can select which version of the library they would like to use.  I
> > can add a <classifer> tag to the pom that would say, e.g. "jvm5" or
> > "optimise".  We could then have these nightlies available on the maven
> > repository (and there for more easily available).
> >
> > Does anyone see any possible ramifications with this idea?  I know of a
> > few areas I'd need to test out with the maven-scala-plugin.  I also know
> > deploying the source artifacts into maven will be a no-go if we use
> > classifiers.  Mark, anything SBT related?
> >
> > - Josh
>
> +1
>
> Java versions are the main example given in maven documentation for
> the use of classifiers.
>
> This also wouldn't interfere with the convention (as used by SBT) of
> embedding Scala version numbers into other libraries.

Classifiers are only useful if libraries will support only one of the jdk
versions.  Presumably most major libraries will support both versions.  
(Otherwise, jdk5 would be effectively abandoned and there would be no need to
distinguish jdk versions.)

A library will then want to produce two jars, one for jdk5 and one for jdk6.  
However, this is the same problem we ran into with cross-building.  You
cannot specify that the jdk5 version of your library depends on
scala-library-jdk5.  This requires different poms, which requires that the
jdk version be encoded in the artifact ID or version.

-1 to classifiers.

Thanks,
Mark

[Josh Suereth]

I think classifiers can be used in that manner (at least I do so at  
work) but I do not think it is common.

The big question here is the explosion of artifacts needing to be  
generated to support a scala version.

If there is a jvm5 branch, and optimized libraries are binary-
incompatible with non-optimized libraries (that's a question I always  
had, and never investigated), then we really need cross-version  
deploying and an explosion of releases for libraries.

I think we ant/maven folk need to get on the ball with what SBT can do  
to solve this issue.  It appears to be getting worse.

Anyway, on reflection, I think classifiers may not be appopriate  
especially as the two artifacts will have different source bundles.

Now the question becomes how to encode the information into a new  
artifact.

I think we prepend the version string with the branch/optimise

I.e

jvm5-optimized-2.8.0-SNAPSHOT

Or

jvm5-2.8.0-RC1

Sent from my iPhone

On Oct 10, 2009, at 10:59 AM, Mark Harrah <harrah@...> wrote:

> On Saturday 10 October 2009, Kevin Wright wrote:
>> On Sat, Oct 10, 2009 at 2:20 PM, Josh Suereth <joshua.suereth@...
>> >
> wrote:
>>> Seems like we should include this in the maven repository as well,  
>>> so
>>> users can select which version of the library they would like to  
>>> use.  I
>>> can add a <classifer> tag to the pom that would say, e.g. "jvm5" or
>>> "optimise".  We could then have these nightlies available on the  
>>> maven
>>> repository (and there for more easily available).
>>>
>>> Does anyone see any possible ramifications with this idea?  I know  
>>> of a
>>> few areas I'd need to test out with the maven-scala-plugin.  I  
>>> also know
>>> deploying the source artifacts into maven will be a no-go if we use
>>> classifiers.  Mark, anything SBT related?
>>>
>>> - Josh
>>
>> +1
>>
>> Java versions are the main example given in maven documentation for
>> the use of classifiers.
>>
>> This also wouldn't interfere with the convention (as used by SBT) of
>> embedding Scala version numbers into other libraries.
>
> Classifiers are only useful if libraries will support only one of  
> the jdk
> versions.  Presumably most major libraries will support both versions.
> (Otherwise, jdk5 would be effectively abandoned and there would be  
> no need to
> distinguish jdk versions.)
>
> A library will then want to produce two jars, one for jdk5 and one  
> for jdk6.
> However, this is the same problem we ran into with cross-building.  
> You
> cannot specify that the jdk5 version of your library depends on
> scala-library-jdk5.  This requires different poms, which requires  
> that the
> jdk version be encoded in the artifact ID or version.
>
> -1 to classifiers.
>
> Thanks,
> Mark

[Kevin Wright-4]

Very valid point about source bundles, as classifiers only apply to
binary artifacts.

There is a real problem here of a combinatorial explosion, all the
worse if it applies at the source level.  Once the 2.8 IDE is
complete, I think this will be the biggest issue facing wider adoption
of the language.

If I include all versions of scala that can arguably be considered
current, we have the following combinations: (ignoring release
candidates and snapshots)

2.7.5              optimized-2.7.5
2.7.7              optimized-2.7.7
jvm5-2.8.0       jvm5-optimized-2.8.0
jvm6-2.8.0       jvm6-optimized-2.8.0
jvm7-2.8.0       jvm7-optimized-2.8.0

And that doesn't even start to cover the issue of targeting
timestamped snapshots...


Perhaps an annotation could be used to limit target jvms for which a
given construct is valid, the compiler (or a plugin) would then use
this to control content in generated classfiles.  That would solve the
question of different source bundles for different jvms, although it
gets dangerously close to full-on metaprograming.

Different scala versions will also need different source trees,
especially given the changes to package declaration and arrays, this
is a necessary evil and isn't something that can be handled with an
annotation hack.

On the plus side, the core Scala libs only need to target different
jvm's from 2.8 onward.  It also makes a lot of sense to use the
qualifier for optimised vs unoptimised releases, as these have
identical source-code







On Sat, Oct 10, 2009 at 4:39 PM, Josh Suereth <joshua.suereth@...> wrote:

> I think classifiers can be used in that manner (at least I do so at work)
> but I do not think it is common.
>
> The big question here is the explosion of artifacts needing to be generated
> to support a scala version.
>
> If there is a jvm5 branch, and optimized libraries are binary-incompatible
> with non-optimized libraries (that's a question I always had, and never
> investigated), then we really need cross-version deploying and an explosion
> of releases for libraries.
>
> I think we ant/maven folk need to get on the ball with what SBT can do to
> solve this issue.  It appears to be getting worse.
>
> Anyway, on reflection, I think classifiers may not be appopriate especially
> as the two artifacts will have different source bundles.
>
> Now the question becomes how to encode the information into a new artifact.
>
> I think we prepend the version string with the branch/optimise
>
> I.e
>
> jvm5-optimized-2.8.0-SNAPSHOT
>
> Or
>
> jvm5-2.8.0-RC1
>
> Sent from my iPhone
>
> On Oct 10, 2009, at 10:59 AM, Mark Harrah <harrah@...> wrote:
>
>> On Saturday 10 October 2009, Kevin Wright wrote:
>>>
>>> On Sat, Oct 10, 2009 at 2:20 PM, Josh Suereth <joshua.suereth@...>
>>
>> wrote:
>>>>
>>>> Seems like we should include this in the maven repository as well, so
>>>> users can select which version of the library they would like to use.  I
>>>> can add a <classifer> tag to the pom that would say, e.g. "jvm5" or
>>>> "optimise".  We could then have these nightlies available on the maven
>>>> repository (and there for more easily available).
>>>>
>>>> Does anyone see any possible ramifications with this idea?  I know of a
>>>> few areas I'd need to test out with the maven-scala-plugin.  I also know
>>>> deploying the source artifacts into maven will be a no-go if we use
>>>> classifiers.  Mark, anything SBT related?
>>>>
>>>> - Josh
>>>
>>> +1
>>>
>>> Java versions are the main example given in maven documentation for
>>> the use of classifiers.
>>>
>>> This also wouldn't interfere with the convention (as used by SBT) of
>>> embedding Scala version numbers into other libraries.
>>
>> Classifiers are only useful if libraries will support only one of the jdk
>> versions.  Presumably most major libraries will support both versions.
>> (Otherwise, jdk5 would be effectively abandoned and there would be no need
>> to
>> distinguish jdk versions.)
>>
>> A library will then want to produce two jars, one for jdk5 and one for
>> jdk6.
>> However, this is the same problem we ran into with cross-building.  You
>> cannot specify that the jdk5 version of your library depends on
>> scala-library-jdk5.  This requires different poms, which requires that the
>> jdk version be encoded in the artifact ID or version.
>>
>> -1 to classifiers.
>>
>> Thanks,
>> Mark
>

[Josh Suereth]

IN terms of IDE support, I really think the Eclipse IDE needs to have some form of adapter against the various scala pieces where the amount of code you need to support for each supported compiler version is small (compared to the entire plugin).

- Josh

On Sat, Oct 10, 2009 at 1:15 PM, Kevin Wright <kev.lee.wright@...> wrote:

Very valid point about source bundles, as classifiers only apply to
binary artifacts.

There is a real problem here of a combinatorial explosion, all the
worse if it applies at the source level.  Once the 2.8 IDE is
complete, I think this will be the biggest issue facing wider adoption
of the language.

If I include all versions of scala that can arguably be considered
current, we have the following combinations: (ignoring release
candidates and snapshots)

2.7.5              optimized-2.7.5
2.7.7              optimized-2.7.7
jvm5-2.8.0       jvm5-optimized-2.8.0
jvm6-2.8.0       jvm6-optimized-2.8.0
jvm7-2.8.0       jvm7-optimized-2.8.0

And that doesn't even start to cover the issue of targeting
timestamped snapshots...


Perhaps an annotation could be used to limit target jvms for which a
given construct is valid, the compiler (or a plugin) would then use
this to control content in generated classfiles.  That would solve the
question of different source bundles for different jvms, although it
gets dangerously close to full-on metaprograming.

Different scala versions will also need different source trees,
especially given the changes to package declaration and arrays, this
is a necessary evil and isn't something that can be handled with an
annotation hack.

On the plus side, the core Scala libs only need to target different
jvm's from 2.8 onward.  It also makes a lot of sense to use the
qualifier for optimised vs unoptimised releases, as these have
identical source-code

On Sat, Oct 10, 2009 at 4:39 PM, Josh Suereth <joshua.suereth@...> wrote:
> I think classifiers can be used in that manner (at least I do so at work)
> but I do not think it is common.
>
> The big question here is the explosion of artifacts needing to be generated
> to support a scala version.
>
> If there is a jvm5 branch, and optimized libraries are binary-incompatible
> with non-optimized libraries (that's a question I always had, and never
> investigated), then we really need cross-version deploying and an explosion
> of releases for libraries.
>
> I think we ant/maven folk need to get on the ball with what SBT can do to
> solve this issue.  It appears to be getting worse.
>
> Anyway, on reflection, I think classifiers may not be appopriate especially
> as the two artifacts will have different source bundles.
>
> Now the question becomes how to encode the information into a new artifact.
>
> I think we prepend the version string with the branch/optimise
>
> I.e
>
> jvm5-optimized-2.8.0-SNAPSHOT
>
> Or
>
> jvm5-2.8.0-RC1
>
> Sent from my iPhone
>
> On Oct 10, 2009, at 10:59 AM, Mark Harrah <harrah@...> wrote:
>
>> On Saturday 10 October 2009, Kevin Wright wrote:
>>>
>>> On Sat, Oct 10, 2009 at 2:20 PM, Josh Suereth <joshua.suereth@...>
>>
>> wrote:
>>>>
>>>> Seems like we should include this in the maven repository as well, so
>>>> users can select which version of the library they would like to use.  I
>>>> can add a <classifer> tag to the pom that would say, e.g. "jvm5" or
>>>> "optimise".  We could then have these nightlies available on the maven
>>>> repository (and there for more easily available).
>>>>
>>>> Does anyone see any possible ramifications with this idea?  I know of a
>>>> few areas I'd need to test out with the maven-scala-plugin.  I also know
>>>> deploying the source artifacts into maven will be a no-go if we use
>>>> classifiers.  Mark, anything SBT related?
>>>>
>>>> - Josh
>>>
>>> +1
>>>
>>> Java versions are the main example given in maven documentation for
>>> the use of classifiers.
>>>
>>> This also wouldn't interfere with the convention (as used by SBT) of
>>> embedding Scala version numbers into other libraries.
>>
>> Classifiers are only useful if libraries will support only one of the jdk
>> versions.  Presumably most major libraries will support both versions.
>> (Otherwise, jdk5 would be effectively abandoned and there would be no need
>> to
>> distinguish jdk versions.)
>>
>> A library will then want to produce two jars, one for jdk5 and one for
>> jdk6.
>> However, this is the same problem we ran into with cross-building.  You
>> cannot specify that the jdk5 version of your library depends on
>> scala-library-jdk5.  This requires different poms, which requires that the
>> jdk version be encoded in the artifact ID or version.
>>
>> -1 to classifiers.
>>
>> Thanks,
>> Mark
>

[Ismael Juma]

On Sat, 2009-10-10 at 09:20 -0400, Josh Suereth wrote:
> Does anyone see any possible ramifications with this idea?  I know of
> a few areas I'd need to test out with the maven-scala-plugin.  I also
> know deploying the source artifacts into maven will be a no-go if we
> use classifiers.

That seems like an important limitation. I find the ability to have
source artifacts very useful.

Best,
Ismael

[Kevin Wright-4]

The problem is, who actually wants to maintain multiple source artifacts?

If I'm releasing a library, then I really don't want to have separate
releases for:
jvm5/scala2.7
jvm5/scala2.8
jvm6/scala2.7
jvm6/scala2.8

It's a bug-fixing nightmare!

Separate version for scala2.7 and 2.8 are acceptable though, which I
see as being very similar to the setup with java 1.5 where folks were
starting to adopt generics.


Much as I want to avoid something like C++ templates (insanely
elegant, but the devil's own nightmare to fix if you run into
problems), we do perhaps need a limited form of meta-programming.
Specifically, the ability to target limited jvms for a given construct
(object, method, etc) via an attribute.

The trick here is that jvm5 and jvm6 (and jvm7) can be targeted with
the same source code, allowing a maven classifier to be used for
different jvms and for optimised code.  That then puts us back to the
scenario of having just 2 codebases (scala 2.7 and 2.8) to maintain.
Still one codebase too many, but at least its workable :)

In this case, we definitely want to use classifiers, otherwise we run
into the opposite problem: it will appear that multiple codebases are
available when they're actually identical.



On Sun, Oct 11, 2009 at 9:51 AM, Ismael Juma <mlists@...> wrote:

> On Sat, 2009-10-10 at 09:20 -0400, Josh Suereth wrote:
>> Does anyone see any possible ramifications with this idea?  I know of
>> a few areas I'd need to test out with the maven-scala-plugin.  I also
>> know deploying the source artifacts into maven will be a no-go if we
>> use classifiers.
>
> That seems like an important limitation. I find the ability to have
> source artifacts very useful.
>
> Best,
> Ismael
>
>

[Ismael Juma]

On Sun, 2009-10-11 at 11:48 +0100, Kevin Wright wrote:
> The problem is, who actually wants to maintain multiple source artifacts?

Maybe we're talking about different things. I am talking about the Scala
library that already has a separate branch for Java 5 (and hence
multiple source artifacts).

Best,
Ismael

[Kevin Wright-4]

On Sun, Oct 11, 2009 at 12:52 PM, Ismael Juma <mlists@...> wrote:

> On Sun, 2009-10-11 at 11:48 +0100, Kevin Wright wrote:
>> The problem is, who actually wants to maintain multiple source artifacts?
>
> Maybe we're talking about different things. I am talking about the Scala
> library that already has a separate branch for Java 5 (and hence
> multiple source artifacts).
>
> Best,
> Ismael
>
>

And I'm wishing that that could have been solved without forking the
source... :)

[Lukas Rytz]

On Sun, Oct 11, 2009 at 13:54, Kevin Wright <kev.lee.wright@...> wrote:

On Sun, Oct 11, 2009 at 12:52 PM, Ismael Juma <mlists@...> wrote:
> On Sun, 2009-10-11 at 11:48 +0100, Kevin Wright wrote:
>> The problem is, who actually wants to maintain multiple source artifacts?
>
> Maybe we're talking about different things. I am talking about the Scala
> library that already has a separate branch for Java 5 (and hence
> multiple source artifacts).
>
> Best,
> Ismael
>
>

And I'm wishing that that could have been solved without forking the
source... :)

We use svnmerge.py to automatically merge changes from trunk into the branch
every night. Except for maybe five lines of code, branches/jvm5 and trunk are
always identical. The differences can be reviewed using diff or meld.

For us, this was the easiest way to have a jvm5 build, we don't need any additional
build scripts.

Cheers: Lukas

[Kevin Wright-4]

On Mon, Oct 12, 2009 at 10:41 AM, Lukas Rytz <lukas.rytz@...> wrote:

>
>
> On Sun, Oct 11, 2009 at 13:54, Kevin Wright <kev.lee.wright@...>
> wrote:
>>
>> On Sun, Oct 11, 2009 at 12:52 PM, Ismael Juma <mlists@...> wrote:
>> > On Sun, 2009-10-11 at 11:48 +0100, Kevin Wright wrote:
>> >> The problem is, who actually wants to maintain multiple source
>> >> artifacts?
>> >
>> > Maybe we're talking about different things. I am talking about the Scala
>> > library that already has a separate branch for Java 5 (and hence
>> > multiple source artifacts).
>> >
>> > Best,
>> > Ismael
>> >
>> >
>>
>> And I'm wishing that that could have been solved without forking the
>> source... :)
>
> We use svnmerge.py to automatically merge changes from trunk into the branch
> every night. Except for maybe five lines of code, branches/jvm5 and trunk
> are
> always identical. The differences can be reviewed using diff or meld.
>
> For us, this was the easiest way to have a jvm5 build, we don't need any
> additional
> build scripts.
>
> Cheers: Lukas
>

Unfortunately, even 5 lines means that the source for jvm5 is not the
same as the source for jvm6, and so requires an entire separate source
distribution in maven.  This means that every other distribution has
to be doubled, so the next 3 scala releases will produce 6 source
artifacts (a jvm5 and jvm6 variant for each)

[David Bernard-3]

A Hack technic used to patch only some classes on a running
application could be used :
the classes that differ in jvm5 from jvm6 could be extracted and
packaged as a separeted jar. if the jar with "patched" classes are
loaded before by classloader, then patched classes will be used.
  00scala-library-patchjvm5.jar

Other solutions, extract actors from scala-library and provide 2
complementary libs scala-actors-jvm6 and scala-actors-jvm5. Actors are
not part of the language is only library. Why every things should be
in a single jar scala-library ?

/davidB

On Mon, Oct 12, 2009 at 11:51, Kevin Wright
<kev.lee.wright@...> wrote:

> On Mon, Oct 12, 2009 at 10:41 AM, Lukas Rytz <lukas.rytz@...> wrote:
>>
>>
>> On Sun, Oct 11, 2009 at 13:54, Kevin Wright <kev.lee.wright@...>
>> wrote:
>>>
>>> On Sun, Oct 11, 2009 at 12:52 PM, Ismael Juma <mlists@...> wrote:
>>> > On Sun, 2009-10-11 at 11:48 +0100, Kevin Wright wrote:
>>> >> The problem is, who actually wants to maintain multiple source
>>> >> artifacts?
>>> >
>>> > Maybe we're talking about different things. I am talking about the Scala
>>> > library that already has a separate branch for Java 5 (and hence
>>> > multiple source artifacts).
>>> >
>>> > Best,
>>> > Ismael
>>> >
>>> >
>>>
>>> And I'm wishing that that could have been solved without forking the
>>> source... :)
>>
>> We use svnmerge.py to automatically merge changes from trunk into the branch
>> every night. Except for maybe five lines of code, branches/jvm5 and trunk
>> are
>> always identical. The differences can be reviewed using diff or meld.
>>
>> For us, this was the easiest way to have a jvm5 build, we don't need any
>> additional
>> build scripts.
>>
>> Cheers: Lukas
>>
>
> Unfortunately, even 5 lines means that the source for jvm5 is not the
> same as the source for jvm6, and so requires an entire separate source
> distribution in maven.  This means that every other distribution has
> to be doubled, so the next 3 scala releases will produce 6 source
> artifacts (a jvm5 and jvm6 variant for each)
>

[_retronym]

Koshuke has built a clever solution for the Hudson [1]: he compiles with jdk6, and statically analyses the compiled code to ensure that references to jdk6 APIs are only made from sections of code marked with an annotation (@IgnoreJRERequirement).

Fitting in with Maven's limited classifier system for source jars is not reason enough to do this. But the prospect of a single binary distribution may be.

Perhaps jdk7 will tip the scales, especially if jdk5 resists deprecation.

-jason

[1] http://weblogs.java.net/blog/2008/11/14/compiling-jdk6-and-running-jdk5

On Mon, Oct 12, 2009 at 11:41 AM, Lukas Rytz <lukas.rytz@...> wrote:

On Sun, Oct 11, 2009 at 13:54, Kevin Wright <kev.lee.wright@...> wrote:

On Sun, Oct 11, 2009 at 12:52 PM, Ismael Juma <mlists@...> wrote:
> On Sun, 2009-10-11 at 11:48 +0100, Kevin Wright wrote:
>> The problem is, who actually wants to maintain multiple source artifacts?
>
> Maybe we're talking about different things. I am talking about the Scala
> library that already has a separate branch for Java 5 (and hence
> multiple source artifacts).
>
> Best,
> Ismael
>
>

And I'm wishing that that could have been solved without forking the
source... :)

We use svnmerge.py to automatically merge changes from trunk into the branch
every night. Except for maybe five lines of code, branches/jvm5 and trunk are
always identical. The differences can be reviewed using diff or meld.

For us, this was the easiest way to have a jvm5 build, we don't need any additional
build scripts.

Cheers: Lukas

[Kevin Wright-4]

On Mon, Oct 12, 2009 at 9:22 PM, David Bernard
<david.bernard.31@...> wrote:

> A Hack technic used to patch only some classes on a running
> application could be used :
> the classes that differ in jvm5 from jvm6 could be extracted and
> packaged as a separeted jar. if the jar with "patched" classes are
> loaded before by classloader, then patched classes will be used.
>  00scala-library-patchjvm5.jar
>
> Other solutions, extract actors from scala-library and provide 2
> complementary libs scala-actors-jvm6 and scala-actors-jvm5. Actors are
> not part of the language is only library. Why every things should be
> in a single jar scala-library ?

Too true!  This one one of the main arguments behind all the
modularization work...

>
> /davidB
>
> On Mon, Oct 12, 2009 at 11:51, Kevin Wright
> <kev.lee.wright@...> wrote:
>> On Mon, Oct 12, 2009 at 10:41 AM, Lukas Rytz <lukas.rytz@...> wrote:
>>>
>>>
>>> On Sun, Oct 11, 2009 at 13:54, Kevin Wright <kev.lee.wright@...>
>>> wrote:
>>>>
>>>> On Sun, Oct 11, 2009 at 12:52 PM, Ismael Juma <mlists@...> wrote:
>>>> > On Sun, 2009-10-11 at 11:48 +0100, Kevin Wright wrote:
>>>> >> The problem is, who actually wants to maintain multiple source
>>>> >> artifacts?
>>>> >
>>>> > Maybe we're talking about different things. I am talking about the Scala
>>>> > library that already has a separate branch for Java 5 (and hence
>>>> > multiple source artifacts).
>>>> >
>>>> > Best,
>>>> > Ismael
>>>> >
>>>> >
>>>>
>>>> And I'm wishing that that could have been solved without forking the
>>>> source... :)
>>>
>>> We use svnmerge.py to automatically merge changes from trunk into the branch
>>> every night. Except for maybe five lines of code, branches/jvm5 and trunk
>>> are
>>> always identical. The differences can be reviewed using diff or meld.
>>>
>>> For us, this was the easiest way to have a jvm5 build, we don't need any
>>> additional
>>> build scripts.
>>>
>>> Cheers: Lukas
>>>
>>
>> Unfortunately, even 5 lines means that the source for jvm5 is not the
>> same as the source for jvm6, and so requires an entire separate source
>> distribution in maven.  This means that every other distribution has
>> to be doubled, so the next 3 scala releases will produce 6 source
>> artifacts (a jvm5 and jvm6 variant for each)
>>
>