SBT 0.11.3 projects and BuildHive

[Johannes Rudolph]

It seems that BuildHive (which provides jenkins builds for your github projects for free) can't build sbt 0.11.3 projects. That's because the sbt 0.11.2 launcher is hard coded into the BuildHive sbt template.

I built a custom sbt-launcher [1] which contains some hard-coded logic [2] to make it work with all the recent sbt versions (0.11.x and 0.12.0-Beta2 at least).

Another possibility would be to make them use the sbt launcher from paulp's sbt-extra.

What do you think should be the solution we should try to get into BuildHive?

I already started an issue at BuildHive documenting the issue and possible solutions [3] (probably private).

Johannes

[1] https://github.com/downloads/jrudolph/xsbt/sbt-launch-all.jar

[2] https://github.com/jrudolph/xsbt/commit/97dbbfe317be11463d6bd1c740da7820e46d4964

[3] https://cloudbees.zendesk.com/requests/3757

[Johannes Rudolph]

I was told to file it here as well:

https://github.com/buildhive/buildhive/issues/7

[Mark Harrah]

On Tue, 22 May 2012 07:32:36 -0700 (PDT)
Johannes Rudolph <johannes...@gmail.com> wrote:

> It seems that BuildHive (which provides jenkins builds for your github
> projects for free) can't build sbt 0.11.3 projects. That's because the sbt
> 0.11.2 launcher is hard coded into the BuildHive sbt template.

I know the situation isn't great. I was hoping not to change the group ID until 0.12, but obviously that didn't happen. I am open to suggestions, although sbt-extra may be the best suggestion. One other possibility would be to have different built-in sbt.boot.properties keyed by the sbt version. I think that could be made generic enough to keep the launcher decoupled from sbt and it might be possible to use this to allow one launcher to work back to 0.7.x.

-Mark

> I built a custom sbt-launcher [1] which contains some hard-coded logic [2]
> to make it work with all the recent sbt versions (0.11.x and 0.12.0-Beta2
> at least).
>
> Another possibility would be to make them use the sbt launcher from paulp's
> sbt-extra.
>
> What do you think should be the solution we should try to get into
> BuildHive?
>
> I already started an issue at BuildHive documenting the issue and possible
> solutions [3] (probably private).
>
> Johannes
>

> [1] https://github.com/downloads/jrudolph/xsbt/sbt-launch-all.jar<https://raw.github.com/paulp/sbt-extras/master/sbt>

[Jason Zaugg]

On Thursday, May 24, 2012 3:56:34 AM UTC+2, Mark Harrah wrote:

On Tue, 22 May 2012 07:32:36 -0700 (PDT)
Johannes Rudolph <johannes...@gmail.com> wrote:

> It seems that BuildHive (which provides jenkins builds for your github
> projects for free) can't build sbt 0.11.3 projects. That's because the sbt
> 0.11.2 launcher is hard coded into the BuildHive sbt template.

I know the situation isn't great.  I was hoping not to change the group ID until 0.12, but obviously that didn't happen.  I am open to suggestions, although sbt-extra may be the best suggestion.  One other possibility would be to have different built-in sbt.boot.properties keyed by the sbt version.  I think that could be made generic enough to keep the launcher decoupled from sbt and it might be possible to use this to allow one launcher to work back to 0.7.x.

This would be an enormous help. I think the best ideas from sbt-extras ought to be brought to a wider audience by rolling them into the standard launcher.

-jason 

[Mark Harrah]

On Wed, 23 May 2012 21:56:34 -0400
Mark Harrah <dmha...@gmail.com> wrote:

> On Tue, 22 May 2012 07:32:36 -0700 (PDT)
> Johannes Rudolph <johannes...@gmail.com> wrote:
>
> > It seems that BuildHive (which provides jenkins builds for your github
> > projects for free) can't build sbt 0.11.3 projects. That's because the sbt
> > 0.11.2 launcher is hard coded into the BuildHive sbt template.
>
> I know the situation isn't great. I was hoping not to change the group ID until 0.12, but obviously that didn't happen. I am open to suggestions, although sbt-extra may be the best suggestion. One other possibility would be to have different built-in sbt.boot.properties keyed by the sbt version. I think that could be made generic enough to keep the launcher decoupled from sbt and it might be possible to use this to allow one launcher to work back to 0.7.x.

I implemented this[1] and the latest nightly launcher[2] includes this change. This launcher should be able to launch 0.7 through 0.12+ based on the sbt.version in project/build.properties. Limitations: it cannot create new 0.7 projects and it can only launch released versions of 0.10.x and 0.11.x (local snapshots and custom versions starting with - should be fine, however). It doesn't reference scala-tools.org in the launcher, but sbt versions before 0.11.3 include scala-tools.org in the default resolvers list.

Please try this out as your launcher. If it works well, I can publish a stable launcher independently of any further releases and have it default to 0.11.3 instead of a snapshot.

-Mark

[1] https://github.com/harrah/xsbt/commit/f39af0bab3e3d4ab3e756864c6adecfd21a5f9c9
[2] http://repo.typesafe.com/typesafe/ivy-snapshots/org.scala-sbt/sbt-launch/0.13.0-20120525-114016/sbt-launch.jar

[Peter Vlugter]

On 26/05/2012, at 1:08 AM, Mark Harrah wrote:

> Please try this out as your launcher. If it works well, I can publish a stable launcher independently of any further releases and have it default to 0.11.3 instead of a snapshot.

Nice. Tried it out on several projects with different sbt versions and it worked well.

Something that the sbt-extras script has by default is per-version boot directories - useful for specifying per-version global settings. Could be a good default in the universal launcher properties as well?

[Mark Harrah]

On Sat, 26 May 2012 13:02:43 +1200
Peter Vlugter <pvlu...@gmail.com> wrote:

> On 26/05/2012, at 1:08 AM, Mark Harrah wrote:
>
> > Please try this out as your launcher. If it works well, I can publish a stable launcher independently of any further releases and have it default to 0.11.3 instead of a snapshot.
>
> Nice. Tried it out on several projects with different sbt versions and it worked well.

Ok, good.

> Something that the sbt-extras script has by default is per-version boot directories - useful for specifying per-version global settings. Could be a good default in the universal launcher properties as well?

This is a setting on the side of the main sbt application and not in the launcher. I believe a change towards this would need to look in ~/.sbt/, ~/.sbt/0.12, and ~/.sbt/0.12.0 for backwards compatibility or stable settings, the common case of settings working across a series, and for use when working around issues in specific versions.

A pull request could make it into 0.12.0, but it isn't otherwise a priority for me for 0.12.0.

-Mark

[Peter Vlugter]

On 27/05/2012, at 5:18 AM, Mark Harrah wrote:

>> Something that the sbt-extras script has by default is per-version boot directories - useful for specifying per-version global settings. Could be a good default in the universal launcher properties as well?
>
> This is a setting on the side of the main sbt application and not in the launcher. I believe a change towards this would need to look in ~/.sbt/, ~/.sbt/0.12, and ~/.sbt/0.12.0 for backwards compatibility or stable settings, the common case of settings working across a series, and for use when working around issues in specific versions.

Yeah, good point. Having it fallback through the other locations would be much better.