Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Use sbt-extras, instead of orginal sbt #107

merged 3 commits into from Nov 23, 2012


None yet
2 participants

gildegoma commented Nov 21, 2012

I propose here to switch from 'legacy sbt launcher script' to sbt-extras variant, which is largely adopted in scala community (even Typesafe forked sbt-extras and package it in its official stack).

Some useful links:



  • Mmmh... sincerly none, and that's why I open this pull request.
  • Of course we always should except to potentially suffer from a bug in sbt-extras, but it would usually be fixed by github community in a reasonable time.
  • Check https://github.com/paulp/sbt-extras/issues

Customization for Travis CI


Project configured for sbt 0.12.1 (already installed on the machine)

travis:~/project1$ sbt test
Detected sbt version 0.12.1
Using /home/travis/.sbt/0.12.1 as sbt dir, -sbt-dir to override.
[info] Loading project definition from ...

Project configured for sbt 0.11.1 (not yet installed on the machine)

travis:~/project2$ sbt test
Detected sbt version 0.11.1
Downloading sbt launcher 0.11.1:
  From  http://typesafe.artifactoryonline.com/typesafe/ivy-releases/org.scala-tools.sbt/sbt-launch/0.11.1/sbt-launch.jar
    To  /opt/sbt-extras/.lib/0.11.1/sbt-launch.jar
Using /home/vagrant/.sbt/0.11.1 as sbt dir, -sbt-dir to override.
Getting net.java.dev.jna jna 3.2.3 ...
downloading http://repo1.maven.org/maven2/net/java/dev/jna/jna/3.2.3/jna-3.2.3.jar ...
  [SUCCESSFUL ] net.java.dev.jna#jna;3.2.3!jna.jar (1650ms)
:: retrieving :: org.scala-tools.sbt#boot-app
  confs: [default]
  1 artifacts copied, 0 already retrieved (838kB/71ms)
Getting Scala 2.9.1 (for sbt)...

This should use node.travis_build_environment.home

Note that node.travis_build_environment.home will return full $HOME value, not just /home or /Users.


gildegoma replied Nov 23, 2012

Should be fixed by 8b48321.

Please use node.travis_build_environment.user here and in other places where you need effective username.


michaelklishin commented Nov 23, 2012

What should we do about version prefixes injected in travis-build? Should those be removed at the same time? Will they be used just fine the way they are used today?

Use travis_build_environment attributes (user, group, home)
(and clean trailing spaces by the way)

attribute overriden by extracting base home directory from travis_build_environment attributes, in order to keep configure the original cookbook (no changes in original recipe code).

Syntax node['travis_build_environment']['user'] used instead of node.travis_build_environement.user to comply with Foodcritic rule FC019 - Access node attributes in a consistent manner

Since travis build machine is single-user oriented, I find easier to maintain and understand to re-use existing 'travis' group, instead creating a new (useless) one.

Absolutely required because Chef load attribute in cookbook-names alphabetic order (without include_attribute, and thus sbt-extras attributes are read before travis_build_environment attributes).

Note: We maybe should 'formally' add same include_attribute statement in ci_environment/zeromq/attributes/default.rb (but not necessary for successful provisioning, because of zeromq cookbook name).


michaelklishin commented Nov 23, 2012

Thank you. So the only question remains about version suffixes for SBT commands we use in travis-build.


gildegoma commented Nov 23, 2012

@michaelklishin asked:

What should we do about version prefixes injected in travis-build? Should those be removed at the same time? Will they be used just fine the way they are used today?

Thanks for asking about that aspect, it is worth to evaluate the alternatives we have here... But before my long speach below: No change required in travis-build, the prefix will still work quite fine!

Good things to know are following:

  • sbt-extras fully supports (actually forwards) ++ <scala-version> argument.
  • sbt-extras provides an equivalent own argument -scala-version <scala-version> that we could use instead. Warning: I actually faced some building errors with this parameter with sbt versions prior to 0.12.x. Not sure if I was doing something wrong, but anyway falling back to ++ always succeeded. So "not recommended" variant.
  • sbt-extras also provides nice other arguments like -28, -29 and -210 that dynamically use the latest release of each major scala versions (at the moment: 2.8.2, 2.9.2 and 2.10.0-RC2 respectively). That could be very nice to integrate such flexibility into travis-build (such kind of meta-version keywords), but there is no hurry for that ;-).

If I write quite a lot here, it is because I definitively think we should debate about the Travis "default scala version" in travis-build. We already discussed about changing the logic of travis-build defaults (see comments in travis-ci/travis-build#17). I know it is maybe something confusing that Travis CI does not set a single default scala version, but I personally find quite nice the idea that Travis default is automatic / project dependant (a.k.a based on project sbt configuration). The following aspects matter when building with sbt:

  • SBT configuration files (e.g. project/ProjectNameBuild.scala) can describe very well which scala versions are supported (e.g. potentially to be built on travis). Why not make travis-build as DRY as possible, by re-using the build metadata described in sbt configuration, instead force the user to duplicate same information in .travis.yml. travis-build could then automatically generate (or validate) the build matrix configuration. I know it's certainly overkill, but it could be nice, no ?
  • With sbt-extras, it is not only the whole scope of scala versions, but also the whole set of sbt versions that are potentially available for any travis build. By hard-coding a scala version in travis-build we force users to override the defaults anytime their project does not match Travis default. A same repository could then have different branches, with different sbt/scala build matrices, but without changing the .travis.yml. That's why I think that the next change in travis-build should be to provide more flexibility / cleverness to the end-user.

In conclusion, I would say that we should keep travis-build unchanged (for this step), but study how to improve it in the near future... (Sorry for so long text)


michaelklishin commented Nov 23, 2012

I agree with your conclusion. If sbt-extras supports prefixes and will use project-specific version by default, that's basically all we can ask for on the Travis side. Thanks for the explanation!

michaelklishin pushed a commit that referenced this pull request Nov 23, 2012

Merge pull request #107 from gildegoma/use-sbt-extras
Use sbt-extras, instead of orginal sbt

@michaelklishin michaelklishin merged commit ee6f43e into travis-ci:master Nov 23, 2012


michaelklishin commented Nov 23, 2012

I will need to test this out with a few projects but looks like all we need is to update Chef run lists in travis-boxes.


gildegoma commented Nov 23, 2012

Thank you for review, merge and future integration!
Yes, I guess that it's only question to provision with new chef run list (the /usr/bin/sbt -> /opt/sbt-extras/sbt will correctly overwrite precedent symlink, and remaining old sbt files should not hurt).
Any problem or wish about sbt-extras cookbook, please report it to https://github.com/gildegoma/chef-sbt-extras.

We'll also need small updates in http://about.travis-ci.org/docs/user/ci-environment/#SBT-version. I can prepare it, unless you prefer to do it by yourself. Just let me know...


gildegoma commented Jan 4, 2013

Hi @michaelklishin ! Happy new Year to you and the whole Travis Team !!!

I noticed that sbt-extras is still not available as default sbt build tool on Travis worker VMs.
I also saw that you renamed the cookbook to replace genuine 'sbt'.

Have you already tried to go live with sbt-extras, or not yet ? I'm afraid you got some troubles... hence I'm coming back on this issue...

If you apply the new sbt-extras cookbook on a brand new vagrant machine, I'm 100% sure it will work fine. But if you try to provision/update an existing VM, with a previous sbt installation (done by former .deb-style sbt cookbook), I can imagine some crashing/conflicting scenarios:

  1. impossible to symlink /opt/sbt-extras/sbt as /usr/bin/sbt, because this inode is already used by a 'real' file
  2. by naming both cookbook 'sbt', maybe the local Chef cache files are messy...

Since the .deb-style is not capabre to clean uninstall its own stuff, I think it will be quite easier to build the VM from scratch. What is actually the general practice by Travis-CI team when you have (major) cookbook changes ?

Regards, while looking forward using sbt-extras on travis!


michaelklishin commented Jan 4, 2013

@gildegoma I am no longer involved with Travis CI actively so the answer is: I don't really know. If the sbt cookbook is rewritten to use sbt-extras, it should be provisioned as soon as the standard image is provisioned and then all specific ones on top of it. You can ask @joshk to help push this live.


gildegoma commented Jan 7, 2013

@joshk Fantastic! Now it works live!!! Thanks a lot!

@gildegoma gildegoma deleted the gildegoma:use-sbt-extras branch Jan 7, 2013

@gildegoma gildegoma referenced this pull request in travis-ci/travis-ci.github.com Jan 8, 2013


Update documentation about SBT (sbt-extras) #186

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment