- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Leveraging the Scala tool chain (cross-post)
Fri, 2010-04-23, 17:29
Folks,
There's a lot of challenge around reproducing complex defects (e.g., Scala defects in Lift or stuff that builds on top of Lift) and verifying fixes is a long cycle and has occasionally led to inter-team friction.
Last night, I realized that there's a potential solution... and it's based on everyone (Scala, ScalaCheck, ScalaTest, Specs, Lift, ScalaZ, Akka, Stambecco, etc.) using sbt and sbt implementing two features: artifact aliasing and dependency chaining.
Basically, the workflow for someone working on the compiler would look like "change the Scala compiler, go to the thing causing the problem, do an "sbt chain-compile alias=scala_280->scala_280_current_local_build_number" That would cause sbt to determine the scala dependencies for the given project, download the source (if it's not already downloaded) for the dependency, check its dependencies, compile the dependency substituting the current Scala built for the named build (compiler and library). This would happen until all the pieces parts were compiled. Yes, the whole build-chain could take a few hours, but for the hard to replicate defects (e.g., the multi-library trait pickling problem) it gives folks a way to validate against the compound, complex library structure that's starting to appear in Scala-land.
The secondary (or perhaps primary benefit) of such a scheme is that it would allow easy set-up of a very complex continuous integration cycle. Basically, as SNAPSHOT artifacts were published, the entirety of what depends on the new artifacts could be recompiled and tested without any pom.xml or whatever munging.
It also means that the CI servers that are publishing snapshot artifacts can keep SNAPSHOT current across the whole tool chain rather than, for example, Lift 2.8 SNAPSHOT building against 2.8 Beta1.
So, I'm committed to migrating Lift to sbt post Lift 2.0 and Stambecco to sbt ASAP. Akka is already on sbt.
What does EPFL think? What does the sbt team think? Can we use the awesomeness of sbt to make all of our lives better and easier?
Thanks,
David
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
There's a lot of challenge around reproducing complex defects (e.g., Scala defects in Lift or stuff that builds on top of Lift) and verifying fixes is a long cycle and has occasionally led to inter-team friction.
Last night, I realized that there's a potential solution... and it's based on everyone (Scala, ScalaCheck, ScalaTest, Specs, Lift, ScalaZ, Akka, Stambecco, etc.) using sbt and sbt implementing two features: artifact aliasing and dependency chaining.
Basically, the workflow for someone working on the compiler would look like "change the Scala compiler, go to the thing causing the problem, do an "sbt chain-compile alias=scala_280->scala_280_current_local_build_number" That would cause sbt to determine the scala dependencies for the given project, download the source (if it's not already downloaded) for the dependency, check its dependencies, compile the dependency substituting the current Scala built for the named build (compiler and library). This would happen until all the pieces parts were compiled. Yes, the whole build-chain could take a few hours, but for the hard to replicate defects (e.g., the multi-library trait pickling problem) it gives folks a way to validate against the compound, complex library structure that's starting to appear in Scala-land.
The secondary (or perhaps primary benefit) of such a scheme is that it would allow easy set-up of a very complex continuous integration cycle. Basically, as SNAPSHOT artifacts were published, the entirety of what depends on the new artifacts could be recompiled and tested without any pom.xml or whatever munging.
It also means that the CI servers that are publishing snapshot artifacts can keep SNAPSHOT current across the whole tool chain rather than, for example, Lift 2.8 SNAPSHOT building against 2.8 Beta1.
So, I'm committed to migrating Lift to sbt post Lift 2.0 and Stambecco to sbt ASAP. Akka is already on sbt.
What does EPFL think? What does the sbt team think? Can we use the awesomeness of sbt to make all of our lives better and easier?
Thanks,
David
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
Fri, 2010-04-23, 18:47
#2
Re: Leveraging the Scala tool chain (cross-post)
> ... and this will certainly weigh into our
> final decision to use SBT or not.
Gilles, will you please clarify "decision" meaning? Is it about including SBT
into official Scala trunk? (I'm asking without any second context, just am
interested in)
Andrew
Fri, 2010-04-23, 22:07
#3
Re: Leveraging the Scala tool chain (cross-post)
On Friday 23 April 2010 01:37:55 pm Andrew Gaydenko wrote:
> > ... and this will certainly weigh into our
> > final decision to use SBT or not.
>
> Gilles, will you please clarify "decision" meaning? Is it about including
> SBT into official Scala trunk? (I'm asking without any second context, just
> am interested in)
The immediate project that Gilles is referring to is building Scala with sbt.
-Mark
Hello.
> Last night, I realized that there's a potential solution... and it's based on everyone (Scala, ScalaCheck, ScalaTest, Specs, Lift, ScalaZ, Akka, Stambecco, etc.) using sbt and sbt implementing two features: artifact aliasing and dependency chaining.
>
> [...]
>
> What does EPFL think? What does the sbt team think? Can we use the awesomeness of sbt to make all of our lives better and easier?
We have a project running right now to try to port Sabbus (the main Ant build file for Scala) to SBT. Gregory Moix is the student doing it (I CCed him this mail). Mark Harrah, from SBT, also said he supports this project.
For the time being, we are still exploring how to implement some parts of the build (the multi-layer build process of Sabbus isn't immediately reproducible in SBT), but I am hopeful we can have a good proof-of-concept within a few weeks. We will then be able to decide whether SBT works for us (in terms of workflow, tool integration and performance).
We'll keep the community informed of our progress. But in principle, I entirely agree with you, David: your proposal would be extremely beneficial to the Scala community, and this will certainly weigh into our final decision to use SBT or not.
Cheers,
Gilles.