0.6.12 (0.7 Beta)

[Mark Harrah]

The experimental 0.6.x series is transitioning to stable. The first step is releasing 0.6.12, which should be considered 0.7 Beta. If you are already on 0.6.x, please consider
updating to 0.6.12 to check for major issues. As usual, you can find the launcher in the downloads section and do 'set sbt.version 0.6.12' to make your project use the new
version.

If 0.6.12 goes well, 0.7 will come after the documentation is updated.

Changes in 0.6.12:

* New launcher that fixes some issues, including filtering 'unknown resolver' messages and permgen errors after several 'reload's.
* Properly match classes back to source files during compilation. There were problems when scalac mangles the name because of its length.
* Machine-global lock on Ivy cache to make it safer to run multiple sbt instances concurrently.
* Implementation of uniform test interface for most test frameworks supported in 0.5.6. This enables running tests with Scala 2.7.x using released versions of frameworks. [1]

Thanks,
Mark

[1] This is automatically enabled when using dependency management. Instructions on using it with manually managed dependencies will come with 0.7. Supported test
frameworks are:
ScalaTest 1.0
specs 1.6.1, 1.6.2
ScalaCheck 1.5, 1.6

[Nathan Hamblen]

> The experimental 0.6.x series is transitioning to stable. The first step is releasing 0.6.12, which should be considered 0.7 Beta. If you are already on 0.6.x, please consider
> updating to 0.6.12 to check for major issues.

I've been testing Dispatch with Specs 1.6.2-SNAPSHOT in the Scala 2.7.6 runtime and that works fine in sbt 0.6.12. I tried swapping in Specs 1.6.1 but none of the tests were picked up. This would be the correct dependency specification, right?

val specs = "org.scala-tools.testing" % "specs" % "1.6.1" % "test->default"

Nathan

[Mark Harrah]

Hey Nathan,

Yes that should be right. You'll notice a test-compat.jar in your
lib_managed/scala_2.7.6/test directory if sbt picked it up properly.

My guess is that your specifications are normal classes. When sbt had
built-in support for specs, it only detected specifications declared
with 'object'. This latest code used by 0.6.12 was more or less a
direct port of that support for compatibility. It seems reasonable to
update it to allow specifications as classes, though.

-Mark

[Erick Fleming]

Mark,

If I wipe out my ~/.ivy2 directory I get: java.io.FileNotFoundException: /home/erick/.ivy2/.sbt.ivy.lock (No such file or directory).

Does not do that with 0.6.10 launcher.  

FYI: Creating the directory fixes it.

--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
To post to this group, send email to simple-b...@googlegroups.com.
To unsubscribe from this group, send email to simple-build-t...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.

--
Erick Fleming

[Mark Harrah]

Thanks Erick. That would have been especially unfortunate for new
users. I've fixed it locally.

-Mark

>> simple-build-t...@googlegroups.com<simple-build-tool%2Bunsu...@googlegroups.com>

[Nathan Hamblen]

On Jan 29, 2010, at 11:57 AM, Mark Harrah wrote:
> My guess is that your specifications are normal classes. When sbt had
> built-in support for specs, it only detected specifications declared
> with 'object'.

That did the trick. Funny thing, I was only using classes because object didn't work with some permutation of sbt and specs versions. I'll go back to object.

Nathan

[huynhjl]

I'm getting this error:

[error] ...: value updateOptions is not a member of sbt.DefaultProject
with ScalaObject
[error] override def updateOptions = super.updateOptions ++ Seq
(CacheDirectory("ivy"))

Was there a change to the updateOptions def?

[Mark Harrah]

Yes, in 0.6.11 [1]. Configuration is by individual methods now:

override def cacheDirectory = Some("ivy".asFile)

Out of curiosity, why do you put the Ivy cache in the project?

Thanks,
Mark

[1] http://groups.google.com/group/simple-build-
tool/browse_thread/thread/81af7649abe20fb9/1a2d134319512e5c

[Mark Harrah]

On Saturday 30 January 2010, Mark Harrah wrote:
> On Saturday 30 January 2010, huynhjl wrote:
> > I'm getting this error:
> >
> > [error] ...: value updateOptions is not a member of sbt.DefaultProject
> > with ScalaObject
> > [error] override def updateOptions = super.updateOptions ++ Seq
> > (CacheDirectory("ivy"))
> >
> > Was there a change to the updateOptions def?
>
> Yes, in 0.6.11 [1]. Configuration is by individual methods now:
>
> override def cacheDirectory = Some("ivy".asFile)

Sorry, this should have been:
override def ivyCacheDirectory = Some(path("ivy"))

> Out of curiosity, why do you put the Ivy cache in the project?
>

> [1] http://groups.google.com/group/simple-build-
> tool/browse_thread/thread/81af7649abe20fb9/1a2d134319512e5c
>

[huynhjl]

>   override def ivyCacheDirectory = Some(path("ivy"))

Thank you, that worked. I'll need to read on the ivy interface.

> Out of curiosity, why do you put the Ivy cache in the project?

Mostly I don't understand ivy, so that makes it easier to track what's
being downloaded. Additionally, I find it easier to reference the jar
from IDEA and check them in the vcs... Is that bad practice? I'll
gladly read more on the topic if there is a documentation somewhere...

[Mark Harrah]

On Saturday 30 January 2010, huynhjl wrote:

> > override def ivyCacheDirectory = Some(path("ivy"))
>
> Thank you, that worked. I'll need to read on the ivy interface.

Note that the documentation on the site is for the last stable release 0.5.6.
I hope to have a new stable release based on 0.6.12 with updated documentation
in the next few days.

> > Out of curiosity, why do you put the Ivy cache in the project?
>
> Mostly I don't understand ivy, so that makes it easier to track what's
> being downloaded. Additionally, I find it easier to reference the jar
> from IDEA and check them in the vcs... Is that bad practice? I'll
> gladly read more on the topic if there is a documentation somewhere...

Ok, I see. Normally, your cache is in <user.home>/.ivy2/cache. This is
shared by all projects on your machine. If you change the cache to be in your
project, you will download jars for each project instead of once per computer.

When you run 'update', sbt retrieves the jars for your project to
'lib_managed'. You can find all jars used by your project there, except for
Scala jars, which are in project/boot/scala-<version>/lib/.

sbt uses Ivy to retrieve these jars and Ivy uses the cache directory mentioned
above to minimize downloading. This is different from Maven, for example,
which uses jars directly out of the cache.

internet -> cache -> <project>/lib_managed

I hope that helps a bit,
Mark