Re: Digest for scala-internals@googlegroups.com - 6 Messages in 1 Topic

On Thu, Aug 4, 2011 at 12:56 PM, Bill Venners wrote:
> I just noticed this conversation. ScalaTest builds with ant, not sbt,
> and I never plan to make ScalaTest depend on sbt. Although I'd prefer
> to use sbt over ant in general, of course, I want to minimize the
> Scala libraries that ScalaTest depends on, so I can get new ScalaTest
> releases out quickly after Scala releases come out.

There isn't any connection between the Scala version that sbt uses
internally and the Scala version (or versions, plural!) that it builds
your project with. So when a new Scala version comes out, you don't
need to wait for anything. You just keep using the sbt you were
already using, and just tell it to including the new Scala version in
your cross-build. It's not a problem.

Furthermore, sbt has very good support for cross-building, so once you
get it set up, it's nearly effortless to build and publish releases
for all of the Scala versions you support.

On Thu, Aug 4, 2011 at 5:56 PM, Bill Venners wrote:
> I just noticed this conversation. ScalaTest builds with ant, not sbt,
> and I never plan to make ScalaTest depend on sbt. Although I'd prefer
> to use sbt over ant in general, of course, I want to minimize the
> Scala libraries that ScalaTest depends on, so I can get new ScalaTest
> releases out quickly after Scala releases come out.

Since Scala will itself depend on sbt to build, it seems to me that
your releases won't be delayed if you depend on sbt.

Best,
Ismael

On Thu, Aug 4, 2011 at 6:08 PM, Seth Tisue <seth@tisue.net> wrote:

There isn't any connection between the Scala version that sbt uses
internally and the Scala version (or versions, plural!) that it builds
your project with.

This is only partially true because SBT relies on compiler API that is semi-public and it breaks when that API is changed.
Best,Ismael

Hey Bill,
I think others may have already stated this, but SBT separates classpaths so you don't have nested Scala dependencies.  I'm actually bootstrapping Scala with SBT right now, and things are working out well.  The only dependency is the JVM.  If you have time sometime this week, feel free to google+ me or call.   I'd love to describe the plans we have to aggregate a whole ton of projects into a gianormous nightly marathon.
- Josh

On Thu, Aug 4, 2011 at 12:56 PM, Bill Venners <bill@artima.com> wrote:

Hi All,

I just noticed this conversation. ScalaTest builds with ant, not sbt,
and I never plan to make ScalaTest depend on sbt. Although I'd prefer
to use sbt over ant in general, of course, I want to minimize the
Scala libraries that ScalaTest depends on, so I can get new ScalaTest
releases out quickly after Scala releases come out. My only Scala
library dependency currently is ScalaCheck, so I only need to wait for
that one. As a result I think ScalaTest should be easy to integrate
into the Scala build if you want to. You need not build and run the
tests. That takes a long time. You could just build the tool itself,
which is relatively quick. If you want it to be sbt 0.10, we could add
a parallel build that just builds the tool and nothing else via sbt
and add that to the project.

Where are the current collections tests, by the way? Are they up on
github somewhere? I'd like to take a look at them.

Thanks.

Bill

On Wed, Aug 3, 2011 at 6:16 AM,
<2Bnoreply [at] googlegroups [dot] com" rel="nofollow">scala-internals+noreply@googlegroups.com> wrote:
>   Today's Topic Summary
>
> Group: http://groups.google.com/group/scala-internals/topics
>
> Collections Testsuite needed? [6 Updates]
>
>  Topic: Collections Testsuite needed?
>
> Ruediger Keller <ruediger.keller@rk42.de> Aug 02 02:00PM +0200 ^
>
> Hi,
>
> I'm looking for some advice.
>
> Would you recommend using Scalacheck only, or would you additionally
> use Specs2 or ScalaTest?
>
> I have no experience with either of them (which is part of the reason
> I'm doing this), but I would like to avoid getting into too many
> things at once.
>
> Regards,
> Rüdiger
>
>
>
>
>
> Josh Suereth <joshua.suereth@gmail.com> Aug 02 08:28AM -0400 ^
>
> Whichever one supports sbt 0.10 is the clincher. For the new Scala build,
> please ensure *everything* works with sbt 0.10 and then it will be trivial
> for us to pull in the project for nightlies. Otherwise, you may be working
> on something that would be too difficult to integrate.
>
> I know scalacheck is ok to use. Not sure about any other testing lib yet.
>
>
>
>
> Ruediger Keller <ruediger.keller@rk42.de> Aug 02 02:45PM +0200 ^
>
> Yes, I'm basing this on sbt 0.10, so no worries there.
>
> sbt 0.10 supports all three testing libs out of the box, it seems, so
> that should be no problem either.
>
> Perhaps I will go with scalacheck only at first and later I tend to
> examine specs2, too.
>
> Regards,
> Rüdiger
>
>
>
>
> Josh Suereth <joshua.suereth@gmail.com> Aug 02 08:49AM -0400 ^
>
> Ah, so here's where the fun comes in. The testing framework must *build*
> with sbt 0.10 so that we can rebuild it with the nightly. There's a chance
> the nightly could break the testing framework, but we'll have to deal with a
> bit of noise from these tests. Better to have them then not. In any case,
> this is slightly safer than relying on binary compatibility, since that can
> change on major Scala versions.
>
> I'm currently working on the sbt 0.10 build for scala itself. We can chat
> offline if you want over all the requirements I'll have to be able to pull
> your project in directly to a Scala nightly build.
>
> - Josh
>
>
>
>
> Paul Phillips <paulp@improving.org> Aug 02 06:00AM -0700 ^
>
> On 8/2/11 5:49 AM, Josh Suereth wrote:
>> I'm currently working on the sbt 0.10 build for scala itself. We can
>> chat offline if you want over all the requirements I'll have to be able
>> to pull your project in directly to a Scala nightly build.
>
> The challenge tends to be more in the completion of the task at hand
> than in the subsequent integration. If my only problem were to be
> figuring out how to integrate useful work into the build, then I would
> be a happy problem sufferer. I say this in case "all the requirements"
> sounds at all imposing: don't worry, this is not where the ship founders.
>
>
>
> Ruediger Keller <ruediger.keller@rk42.de> Aug 02 03:14PM +0200 ^
>
> Ok, now I get it! :-)
>
> Scalacheck is safe then, it builds with sbt 0.10, it seems.
>
> I will get back to you, when I have something remotely presentable, or
> with some more questions.
>
> Regards,
> Rüdiger
>
>
>



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

On Thursday, August 4, 2011 1:47:48 PM UTC-4, ijuma wrote:

On Thu, Aug 4, 2011 at 6:08 PM, Seth Tisue <se...@tisue.net> wrote:

There isn't any connection between the Scala version that sbt uses
internally and the Scala version (or versions, plural!) that it builds
your project with.

This is only partially true because SBT relies on compiler API that is semi-public and it breaks when that API is changed.

Shhhhhhhh!!!! We're trying to convince Bill :-)
Yeah, it has happened (sbt 2.7.7 + Scala 2.9.1.RC1 = boom), but only very rarely.
-- Seth Tisue | Northwestern University | http://tisue.netlead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

I have ScalaTest branches from two or three years ago that I could
revive. I could also try to migrate them to sbt 0.10. I couldn't turn
around and have it done by tomorrow, but I could get it done within a
week I think.

Here is one such branch: http://code.google.com/p/scalatest/source/browse/#svn%2Fbranches%2Fjosh-...

On Aug 4, 12:59 pm, Josh Suereth wrote:
> Hey Bill,
>
> I think others may have already stated this, but SBT separates classpaths so
> you don't have nested Scala dependencies.  I'm actually bootstrapping Scala
> with SBT right now, and things are working out well.  The only dependency is
> the JVM.  If you have time sometime this week, feel free to google+ me or
> call.   I'd love to describe the plans we have to aggregate a whole ton of
> projects into a gianormous nightly marathon.
>
> - Josh
>
>
>
>
>
>
>
> On Thu, Aug 4, 2011 at 12:56 PM, Bill Venners wrote:
> > Hi All,
>
> > I just noticed this conversation. ScalaTest builds with ant, not sbt,
> > and I never plan to make ScalaTest depend on sbt. Although I'd prefer
> > to use sbt over ant in general, of course, I want to minimize the
> > Scala libraries that ScalaTest depends on, so I can get new ScalaTest
> > releases out quickly after Scala releases come out. My only Scala
> > library dependency currently is ScalaCheck, so I only need to wait for
> > that one. As a result I think ScalaTest should be easy to integrate
> > into the Scala build if you want to. You need not build and run the
> > tests. That takes a long time. You could just build the tool itself,
> > which is relatively quick. If you want it to be sbt 0.10, we could add
> > a parallel build that just builds the tool and nothing else via sbt
> > and add that to the project.
>
> > Where are the current collections tests, by the way? Are they up on
> > github somewhere? I'd like to take a look at them.
>
> > Thanks.
>
> > Bill
>
> > On Wed, Aug 3, 2011 at 6:16 AM,
> > wrote:
> > >   Today's Topic Summary
>
> > > Group:http://groups.google.com/group/scala-internals/topics
>
> > > Collections Testsuite needed? [6 Updates]
>
> > >  Topic: Collections Testsuite needed?
>
> > > Ruediger Keller Aug 02 02:00PM +0200 ^
>
> > > Hi,
>
> > > I'm looking for some advice.
>
> > > Would you recommend using Scalacheck only, or would you additionally
> > > use Specs2 or ScalaTest?
>
> > > I have no experience with either of them (which is part of the reason
> > > I'm doing this), but I would like to avoid getting into too many
> > > things at once.
>
> > > Regards,
> > > Rüdiger
>
> > > Josh Suereth Aug 02 08:28AM -0400 ^
>
> > > Whichever one supports sbt 0.10 is the clincher. For the new Scala build,
> > > please ensure *everything* works with sbt 0.10 and then it will be
> > trivial
> > > for us to pull in the project for nightlies. Otherwise, you may be
> > working
> > > on something that would be too difficult to integrate.
>
> > > I know scalacheck is ok to use. Not sure about any other testing lib yet.
>
> > > Ruediger Keller Aug 02 02:45PM +0200 ^
>
> > > Yes, I'm basing this on sbt 0.10, so no worries there.
>
> > > sbt 0.10 supports all three testing libs out of the box, it seems, so
> > > that should be no problem either.
>
> > > Perhaps I will go with scalacheck only at first and later I tend to
> > > examine specs2, too.
>
> > > Regards,
> > > Rüdiger
>
> > > Josh Suereth Aug 02 08:49AM -0400 ^
>
> > > Ah, so here's where the fun comes in. The testing framework must *build*
> > > with sbt 0.10 so that we can rebuild it with the nightly. There's a
> > chance
> > > the nightly could break the testing framework, but we'll have to deal
> > with a
> > > bit of noise from these tests. Better to have them then not. In any case,
> > > this is slightly safer than relying on binary compatibility, since that
> > can
> > > change on major Scala versions.
>
> > > I'm currently working on the sbt 0.10 build for scala itself. We can chat
> > > offline if you want over all the requirements I'll have to be able to
> > pull
> > > your project in directly to a Scala nightly build.
>
> > > - Josh
>
> > > Paul Phillips Aug 02 06:00AM -0700 ^
>
> > > On 8/2/11 5:49 AM, Josh Suereth wrote:
> > >> I'm currently working on the sbt 0.10 build for scala itself. We can
> > >> chat offline if you want over all the requirements I'll have to be able
> > >> to pull your project in directly to a Scala nightly build.
>
> > > The challenge tends to be more in the completion of the task at hand
> > > than in the subsequent integration. If my only problem were to be
> > > figuring out how to integrate useful work into the build, then I would
> > > be a happy problem sufferer. I say this in case "all the requirements"
> > > sounds at all imposing: don't worry, this is not where the ship founders.
>
> > > Ruediger Keller Aug 02 03:14PM +0200 ^
>
> > > Ok, now I get it! :-)
>
> > > Scalacheck is safe then, it builds with sbt 0.10, it seems.
>
> > > I will get back to you, when I have something remotely presentable, or
> > > with some more questions.
>
> > > Regards,
> > > Rüdiger
>
> > --
> > Bill Venners
> > Artima, Inc.
> >http://www.artima.com