Cross Building SLF4S against Scala versions
Hi, Other than Java, Scala software must use the same Scala version for build and runtime. Because of this binary incompatibility Scala projects must be built against different Scala versions, also known as cross building. There is excellent support for cross building in SBT [1], but ASFAIK not in the Maven Scala plugin. As we will probably see Scala 2.8.1 end of this year and milestones and release candidates even earlier, this is an important issue for SLF4S. How could we deal with that? (a) Switch the whole build from Maven to SBT: Not sure if that makes sense for a +95% Java project (b) Try to only build slf4j-scala with SBT: No clue how to integrate SBT and Maven; also publishing/deploying will be an issue due to different naming strategies for artifacts [2] (c) Keep things as they are, i.e. SLF4S as a separate Scala project I hope someone comes up with a (d) ... Heiko [1] http://code.google.com/p/simple-build-tool/wiki/CrossBuild [2] http://code.google.com/p/simple-build-tool/wiki/LibraryManagement Company: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org
On 07/09/2010 8:08 PM, Heiko Seeberger wrote:
Hi,
Other than Java, Scala software must use the same Scala version for build and runtime. Because of this binary incompatibility Scala projects must be built against different Scala versions, also known as cross building. There is excellent support for cross building in SBT [1], but ASFAIK not in the Maven Scala plugin.
As we will probably see Scala 2.8.1 end of this year and milestones and release candidates even earlier, this is an important issue for SLF4S. How could we deal with that?
There is no way 2.8.1 will be (or can be) incompatible with 2.8. The 2.7 to 2.8 binary incompatibility was a single fluke occurrence.
(a) Switch the whole build from Maven to SBT: Not sure if that makes sense for a +95% Java project (b) Try to only build slf4j-scala with SBT: No clue how to integrate SBT and Maven; also publishing/deploying will be an issue due to different naming strategies for artifacts [2] (c) Keep things as they are, i.e. SLF4S as a separate Scala project
b) seems like a reasonable option. I m guessing that SBT can create maven artifacts. d) Be simplistic and only target scala 2.8. For example, akka only targets 2.8 in its latest release. I am confident that for a new library like slf4j-scala, we can get away with targeting only 2.8. Let's go for d.
Heiko
-- Ceki
On 07/09/2010 10:53 PM, Ceki Gülcü wrote:
On 07/09/2010 8:08 PM, Heiko Seeberger wrote:
As we will probably see Scala 2.8.1 end of this year and milestones and release candidates even earlier, this is an important issue for SLF4S. How could we deal with that?
There is no way 2.8.1 will be (or can be) incompatible with 2.8. The 2.7 to 2.8 binary incompatibility was a single fluke occurrence.
2.8.1 will be binary compatible with 2.8.0. See http://bit.ly/93ie5V
Hi Ceki, Different Scala versions are binary incompatible and I don't believe that will change in the near future, even if Martin has said that once. IMHO 2.8.1 will not be binary compatible with 2.8.0. And 2.8.2 won't be with 2.8.1 nor with 2.8.0. And of course neither of these is compatible with 2.7.x. If you are interested in the reasons, you will find numerous resources on the web, e.g. [1] or [2]. Maybe starting from 2.9 EPFL will manage to solve that issue. But that's not a reason to pack and go home. The solution is simple: Cross-build your libraries and frameworks against all the versions you want to support. If you look at an example of such a library deployed to a Maven style repository you will see that the artifact ID is suffixed with _2.8.0 or whatever Scala version [3]. So there is not only the project version but also the Scala version. SBT [4] makes that very easy, but I think I know a solution for Maven, too. Akka has not yet been released (only milestones) and therefore they can target only one Scala version. But they already do it the style I described, i.e. they are ready for multiple versions. Lift already does builds against 2.7.7 and 2.8.0. And there will be others. For something as widespread as SLF4J there in NO WAY not supporting 2.7.7 plus 2.8.0 plus 2.8.x. It just must be cross-built. So your (d) is not an option, but as I already mentioned I hope to find a Maven based solution. Heiko [1] http://stackoverflow.com/questions/2053265/scala-binary-incompatibility-betw... [2] http://it-republik.de/jaxenter/news/Scala---Die-Reifepruefung-056248.html [3] http://scala-tools.org/repo-releases/com/weiglewilczek/scalamodules/scalamod... [4] http://code.google.com/p/simple-build-tool/ On 7 September 2010 22:59, Ceki Gülcü <ceki@qos.ch> wrote:
On 07/09/2010 10:53 PM, Ceki Gülcü wrote:
On 07/09/2010 8:08 PM, Heiko Seeberger wrote:
As we will probably see Scala 2.8.1 end of this year and milestones and
release candidates even earlier, this is an important issue for SLF4S. How could we deal with that?
There is no way 2.8.1 will be (or can be) incompatible with 2.8. The 2.7 to 2.8 binary incompatibility was a single fluke occurrence.
2.8.1 will be binary compatible with 2.8.0. See http://bit.ly/93ie5V
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
-- Heiko Seeberger Company: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org
And here comes the solution: http://github.com/hseeberger/scala-profiles-demo Run Maven twice: 1. mvn install 2. mvn -Pscala-2.7.7 install You wil get exactly what we need: ./scala-profiles-demo_2.7.7 ./scala-profiles-demo_2.7.7/1.0-SNAPSHOT ./scala-profiles-demo_2.7.7/1.0-SNAPSHOT/maven-metadata-local.xml ./scala-profiles-demo_2.7.7/1.0-SNAPSHOT/scala-profiles-demo_2.7.7-1.0-SNAPSHOT.jar ./scala-profiles-demo_2.7.7/1.0-SNAPSHOT/scala-profiles-demo_2.7.7-1.0-SNAPSHOT.pom ./scala-profiles-demo_2.7.7/maven-metadata-local.xml ./scala-profiles-demo_2.8.0 ./scala-profiles-demo_2.8.0/1.0-SNAPSHOT ./scala-profiles-demo_2.8.0/1.0-SNAPSHOT/maven-metadata-local.xml ./scala-profiles-demo_2.8.0/1.0-SNAPSHOT/scala-profiles-demo_2.8.0-1.0-SNAPSHOT.jar ./scala-profiles-demo_2.8.0/1.0-SNAPSHOT/scala-profiles-demo_2.8.0-1.0-SNAPSHOT.pom ./scala-profiles-demo_2.8.0/maven-metadata-local.xml Heiko On 8 September 2010 08:19, Heiko Seeberger <heiko.seeberger@googlemail.com>wrote:
Hi Ceki,
Different Scala versions are binary incompatible and I don't believe that will change in the near future, even if Martin has said that once. IMHO 2.8.1 will not be binary compatible with 2.8.0. And 2.8.2 won't be with 2.8.1 nor with 2.8.0. And of course neither of these is compatible with 2.7.x. If you are interested in the reasons, you will find numerous resources on the web, e.g. [1] or [2]. Maybe starting from 2.9 EPFL will manage to solve that issue.
But that's not a reason to pack and go home. The solution is simple: Cross-build your libraries and frameworks against all the versions you want to support. If you look at an example of such a library deployed to a Maven style repository you will see that the artifact ID is suffixed with _2.8.0 or whatever Scala version [3]. So there is not only the project version but also the Scala version. SBT [4] makes that very easy, but I think I know a solution for Maven, too.
Akka has not yet been released (only milestones) and therefore they can target only one Scala version. But they already do it the style I described, i.e. they are ready for multiple versions. Lift already does builds against 2.7.7 and 2.8.0. And there will be others.
For something as widespread as SLF4J there in NO WAY not supporting 2.7.7 plus 2.8.0 plus 2.8.x. It just must be cross-built.
So your (d) is not an option, but as I already mentioned I hope to find a Maven based solution.
Heiko
[1] http://stackoverflow.com/questions/2053265/scala-binary-incompatibility-betw... [2] http://it-republik.de/jaxenter/news/Scala---Die-Reifepruefung-056248.html [3] http://scala-tools.org/repo-releases/com/weiglewilczek/scalamodules/scalamod... [4] http://code.google.com/p/simple-build-tool/
On 7 September 2010 22:59, Ceki Gülcü <ceki@qos.ch> wrote:
On 07/09/2010 10:53 PM, Ceki Gülcü wrote:
On 07/09/2010 8:08 PM, Heiko Seeberger wrote:
As we will probably see Scala 2.8.1 end of this year and milestones and
release candidates even earlier, this is an important issue for SLF4S. How could we deal with that?
There is no way 2.8.1 will be (or can be) incompatible with 2.8. The 2.7 to 2.8 binary incompatibility was a single fluke occurrence.
2.8.1 will be binary compatible with 2.8.0. See http://bit.ly/93ie5V
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
-- Heiko Seeberger
Company: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org
-- Heiko Seeberger Company: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org
Hi Heiko, Work nicely indeed. I could successfully execute the 'mvn deploy' command as well. By the way, the correct sequence is: Run Maven twice: 1. mvn install 2. mvn clean 3. mvn -Pscala-2.7.7 install Without the intermediary clean the 2.7. compiler does not kick in. It all seems to nicely fall into place. On 08/09/2010 8:33 AM, Heiko Seeberger wrote:
And here comes the solution: http://github.com/hseeberger/scala-profiles-demo
Run Maven twice: 1. mvn install 2. mvn -Pscala-2.7.7 install
You wil get exactly what we need: ./scala-profiles-demo_2.7.7 ./scala-profiles-demo_2.7.7/1.0-SNAPSHOT ./scala-profiles-demo_2.7.7/1.0-SNAPSHOT/maven-metadata-local.xml ./scala-profiles-demo_2.7.7/1.0-SNAPSHOT/scala-profiles-demo_2.7.7-1.0-SNAPSHOT.jar ./scala-profiles-demo_2.7.7/1.0-SNAPSHOT/scala-profiles-demo_2.7.7-1.0-SNAPSHOT.pom ./scala-profiles-demo_2.7.7/maven-metadata-local.xml ./scala-profiles-demo_2.8.0 ./scala-profiles-demo_2.8.0/1.0-SNAPSHOT ./scala-profiles-demo_2.8.0/1.0-SNAPSHOT/maven-metadata-local.xml ./scala-profiles-demo_2.8.0/1.0-SNAPSHOT/scala-profiles-demo_2.8.0-1.0-SNAPSHOT.jar ./scala-profiles-demo_2.8.0/1.0-SNAPSHOT/scala-profiles-demo_2.8.0-1.0-SNAPSHOT.pom ./scala-profiles-demo_2.8.0/maven-metadata-local.xml
Heiko
On 8 September 2010 08:19, Heiko Seeberger <heiko.seeberger@googlemail.com <mailto:heiko.seeberger@googlemail.com>> wrote:
Hi Ceki,
Different Scala versions are binary incompatible and I don't believe that will change in the near future, even if Martin has said that once. IMHO 2.8.1 will not be binary compatible with 2.8.0. And 2.8.2 won't be with 2.8.1 nor with 2.8.0. And of course neither of these is compatible with 2.7.x. If you are interested in the reasons, you will find numerous resources on the web, e.g. [1] or [2]. Maybe starting from 2.9 EPFL will manage to solve that issue.
But that's not a reason to pack and go home. The solution is simple: Cross-build your libraries and frameworks against all the versions you want to support. If you look at an example of such a library deployed to a Maven style repository you will see that the artifact ID is suffixed with _2.8.0 or whatever Scala version [3]. So there is not only the project version but also the Scala version. SBT [4] makes that very easy, but I think I know a solution for Maven, too.
Akka has not yet been released (only milestones) and therefore they can target only one Scala version. But they already do it the style I described, i.e. they are ready for multiple versions. Lift already does builds against 2.7.7 and 2.8.0. And there will be others.
For something as widespread as SLF4J there in NO WAY not supporting 2.7.7 plus 2.8.0 plus 2.8.x. It just must be cross-built.
So your (d) is not an option, but as I already mentioned I hope to find a Maven based solution.
Heiko
[1] http://stackoverflow.com/questions/2053265/scala-binary-incompatibility-betw... [2] http://it-republik.de/jaxenter/news/Scala---Die-Reifepruefung-056248.html [3] http://scala-tools.org/repo-releases/com/weiglewilczek/scalamodules/scalamod... [4] http://code.google.com/p/simple-build-tool/
On 7 September 2010 22:59, Ceki Gülcü <ceki@qos.ch <mailto:ceki@qos.ch>> wrote:
On 07/09/2010 10:53 PM, Ceki Gülcü wrote:
On 07/09/2010 8:08 PM, Heiko Seeberger wrote:
As we will probably see Scala 2.8.1 end of this year and milestones and release candidates even earlier, this is an important issue for SLF4S. How could we deal with that?
There is no way 2.8.1 will be (or can be) incompatible with 2.8. The 2.7 to 2.8 binary incompatibility was a single fluke occurrence.
2.8.1 will be binary compatible with 2.8.0. See http://bit.ly/93ie5V
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch <mailto:slf4j-dev@qos.ch> http://qos.ch/mailman/listinfo/slf4j-dev
-- Heiko Seeberger
On 08/09/2010 8:19 AM, Heiko Seeberger wrote:
Hi Ceki,
Different Scala versions are binary incompatible and I don't believe that will change in the near future, even if Martin has said that once. IMHO 2.8.1 will not be binary compatible with 2.8.0. And 2.8.2 won't be with 2.8.1 nor with 2.8.0. And of course neither of these is compatible with 2.7.x. If you are interested in the reasons, you will find numerous resources on the web, e.g. [1] or [2]. Maybe starting from 2.9 EPFL will manage to solve that issue.
I hope they do. [cut]
Akka has not yet been released (only milestones) and therefore they can target only one Scala version. But they already do it the style I described, i.e. they are ready for multiple versions. Lift already does builds against 2.7.7 and 2.8.0. And there will be others.
For something as widespread as SLF4J there in NO WAY not supporting 2.7.7 plus 2.8.0 plus 2.8.x. It just must be cross-built.
Indeed.
So your (d) is not an option, but as I already mentioned I hope to find a Maven based solution.
and you have... Nicely done.
Heiko
[1] http://stackoverflow.com/questions/2053265/scala-binary-incompatibility-betw...
So it seems that traits are the culprit. -- Ceki
participants (2)
-
Ceki Gülcü -
Heiko Seeberger