heroku / heroku-buildpack-scala

Heroku's buildpack for Scala applications.

Heroku Buildpack for Scala

This is the official Heroku buildpack for Scala apps.

How it works

The buildpack will detect your app as Scala if it has a project/build.properties file and either a .sbt or .scala based build config (for example, a build.sbt file). It vendors a version of sbt into your slug (if you are not using sbt-native-packager, it also includes your popluated .ivy/cache in the slug). The .ivy2 directory will be cached between builds to allow for faster build times.

It is strongly recommended that you use sbt-native-packager with this buildpack instead of sbt-start-script. The latter is deprecated, and will result in exessively large slug sizes.

Documentation

For more information about using Scala and buildpacks on Heroku, see these articles:

• Heroku's Scala Support
• Play Documentation: Deploying to Heroku
• Customizing the JDK
• Running a Remote sbt Console for a Scala or Play Application
• Using Node.js to perform JavaScript optimization for Play and Scala applications
• Reducing the Slug Size of Play 2.x Applications

Examples

There are a number of example applications that demonstrate various ways of configuring a project for use on Heroku. Here are a few:

• Play Database seed
• Play Silhouette Angular seed
• Minimal sbt example
• Lift example

Customizing

This buildpack uses sbt-extras to run sbt. In this way, the execution of sbt can be customized either by setting the SBT_OPTS config variable, or by creating a .sbtopts file in the root directory of your project. When passing options to the underlying sbt JVM, you must prefix them with -J. Thus, setting stack size for the compile process would look like this:

$ heroku config:set SBT_OPTS="-J-Xss4m"

Running additional tasks before the build

Sometimes, it might be necessary to run additional sbt tasks before a build and deployment (for example, database migrations). Ideally, the tasks should be interdependent such that these tasks run automatically as pre-requisities to compile stage, but sometimes this might not be the case. To add any additional tasks, set the environment variable SBT_PRE_TASKS to a list of tasks that should be executed. If the following is set:

SBT_PRE_TASKS=flyway:migrate info

Then, the following command will be run for build:

sbt flyway:migrate info compile stage

Clean builds

In some cases, builds need to clean artifacts before compiling. If a clean build is necessary, configure builds to perform clean by setting SBT_CLEAN=true:

$ heroku config:set SBT_CLEAN=true
Setting config vars and restarting example-app... done, v17
SBT_CLEAN: true

All subsequent deploys will use the clean task. To remove the clean task, unset SBT_CLEAN:

$ heroku config:unset SBT_CLEAN
Unsetting SBT_CLEAN and restarting example-app... done, v18

Development

To make changes to this buildpack, fork it on Github. Push up changes to your fork, then create a new Heroku app to test it, or configure an existing app to use your buildpack:

# Create a new Heroku app that uses your buildpack
heroku create --buildpack <your-github-url>

# Configure an existing Heroku app to use your buildpack
heroku buildpacks:set <your-github-url>

# You can also use a git branch!
heroku buildpacks:set <your-github-url>#your-branch

License

Licensed under the MIT License. See LICENSE file.

heroku-buildpack-scala's Issues

Disable colors on SBT build output

request received via @jroper

SBT likes to output stuff with formatted colours, and Play 2.0, which now uses SBT (note play 2 and play 1 use completely different build frameworks, when deploying a play 2 app to cedar it is detected and built as a Scala app, not a play app) makes extensive use of this feature. This is nice, except when deploying, which is very often done from automated scripts, eg from Jenkins or some other CI server, or from other automated scripts, not directly from a console. It's often necessary to work with the logs in something that isn't a console, for example, in Jenkins you view the logs on a webpage, or you might be reading the logs in an editor. If you try to do this, what you get is output that looks something like this:

� Imagine stuff with ansi colour codes on it, because github kills it.

So in these cases it is necessary to turn the colours off. This is very simple to do, just pass the following argument to SBT:

-Dsbt.log.noformat=true

Thoughts? It sounds like a sensible default, being the output is piped through git.

Shorten SNAPSHOT dependency caching time

I am using -SNAPSHOT releases of one of my dependencies (squeryl), because my project depends on features not yet in a GA release. (Of course this is only for development -- I don't plan to release before those features are released.)

In one occasion the squeryl development team fixed a problem which was affecting me, producing a new -SNAPSHOT. It took several days (four, I'd say) for the buildpack to drop the cached version and download that new one. This delayed my development (not much, but it's a pet/home project, it would have been serious in a work project).

I suggest that the caching strategy is revised to always check for changed -SNAPSHOT releases (more specifically, releases marked as changing by sbt), or at least reduce their caching time.

sbt 0.12.2-RC2 is not recognized as a supported version

The problem is due to the regular expression used to detect the sbt version: https://github.com/heroku/heroku-buildpack-scala/blob/master/bin/common#L49

Error while deploying Play 2.2x app with SBT v0.13.0 on Heroku

Hi,
Me and my team mate (@bhrizvi) tried to deploy our Play 2.2x application with SBT version 0.13.0 on Heroku and still get the same error as seen in the attached image. What could we be doing wrong here?

Also tried with other previous versions of SBT but that didn't help.

support sbt 0.13.11

following code does not match 0.13.11

sbtVersion=$(expr "$sbtVersionLine" : 'sbt\.version=\(0\.1[1-3]\.[0-9]\(-[a-zA-Z0-9_]*\)*\)$')

heroku-buildpack-scala/lib/common.sh

Line 135 in 20d03d9

sbtVersion=$(expr "$sbtVersionLine" : 'sbt\.version=\(0\.1[1-3]\.[0-9]\(-[a-zA-Z0-9_]*\)*\)$')

How skip or remove the documentation of the app ?

Hello everybody,

I want to know if it's possible to not generate the documentation like this:

Main Scala API documentation to /tmp/scala_buildpack_build_dir/target/scala-2.10/api...

Or remove this after it was generated.

Regards

Play 2.0: Ivy Cache Being Dropped Too Early

When deploying Play 2.0 apps, the ivy cache is being dropped from the slug before it is repacked into the CACHE_DIR, which means all deps have to re-downloaded on every deploy. Fix currently in #play-cache branch.

.sbt_home/.ivy2 grows forever

There needs to be a way to clear out the .sbt_home/.ivy2 occasionally. Our slug clocked in at ~220MB and was rejected. After we made a fork of the buildpack to not copy over the .sbt_home/.ivy2 cache this dropped to ~125MB.

Problems when upgrading from sbt 0.13.x to 1.x ?

I've bumped version of sbt and sbt-native-packager to latest available, and started getting these errors in every build:

       [info] Compiling 2 Scala sources to /tmp/scala_buildpack_build_dir/.sbt_home/plugins/target/scala-2.12/sbt-1.0/classes ...

       [info] Non-compiled module 'compiler-bridge_2.12' for Scala 2.12.3. Compiling...

       [info]   Compilation completed in 17.479s.

       [error] /tmp/scala_buildpack_build_dir/.sbt_home/plugins/HerokuBuildpackPlugin_sbt1.scala:4:8: HerokuBuildpackPlugin is already defined as object HerokuBuildpackPlugin

       [error] object HerokuBuildpackPlugin extends AutoPlugin {

       [error]        ^

       [error] one error found

       [error] (compile:compileIncremental) Compilation failed

       Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore? 

 !     ERROR: Failed to run sbt!

I've tried to build with heroku config:set SBT_CLEAN=true , but it still fails.
What I'm doing wrong?

Request for SBT_POST_TASKS

It would be extremely handy if this build pack had SBT_POST_TASKS, implemented in a very similar way as SBT_PRE_TASKS

That task could be used to perform some cleanup operations.

One of the challenges is that a Play project with multiple modules will exceed the slug size limits very quickly. Unfortunately guideline to reduce slug size via overriding stage task (as proposed here) do not work.

Also, having in mind that SBT is quite dynamically changing tool, having a solution nearly independent of SBT version would be ideal.

Use dev database instead of shared database in release

Remove coursier cache from slug

Coursier leaves a large .sbt_home/.cache/coursier/ directory in the slug. I'm not sure what it's job is, but it can probably be removed from the slug and kept in the build cache.

Set `sbt.global.base` in bin/compile

[warn] The global sbt directory is now versioned and is located at /tmp/build_8e0b00ba-86b6-404c-be7d-41627a461661/.sbt_home/.sbt/0.13.
[warn]   You are seeing this warning because there is global configuration in /tmp/build_8e0b00ba-86b6-404c-be7d-41627a461661/.sbt_home/.sbt but not in /tmp/build_8e0b00ba-86b6-404c-be7d-41627a461661/.sbt_home/.sbt/0.13.
[warn]   The global sbt directory may be changed via the sbt.global.base system property.
[info] Loading project definition from /tmp/build_8e0b00ba-86b6-404c-be7d-41627a461661/project
[warn] Multiple resolvers having different access mechanism configured with same name 'typesafe-ivy-releases'. To avoid conflict, Remove duplicate project resolvers (`resolvers`) or rename publishing resolver (`publishTo`).

Add java-agent to /app/.java-agent

Pull java-agent into slugs so people can use it as needed.

Remove old sbt versions from cache

When an app upgrades from one version of sbt to another, we should remove the old version as to prevent the cache from growing too large.

EBean issue

ebean.properties doesn't always get loaded when the app is launched. This results in errors initializing ebean when using ebean.encryptKeyManager and @Encrypted annotations. This appears to be a difference between using play run and running on Heroku

Example code can be found in the app morning-brushlands-4140

Skip doc generation

Some Scala builds are generating docs are part of the build process:

[info] Generating Scala API documentation for main sources

This should be skipped.

Commented out version of SBT is detected

From a support ticket:

"Was getting a deployment error when deploying a Play Framework 2.0.4 app as follows:

-----> Heroku receiving push
-----> Play 2.0 - Scala app detected
! Error, you have defined an unsupported sbt.version in project/build.properties
! You must use a release verison of sbt, sbt.version=0.11.0 or greater
! Heroku push rejected, failed to compile Play 2.0 - scala app

my project/build.properties file was as follows:

sbt.version=0.12.0

sbt.version=0.11.3

when I removed the 'commented' line, it got past the error. Something is probably parsing commented lines to determine sbt.version, becoming confused, and failing the deploy because of a commented line."

SBT launcher and ivy cache downloaded over HTTP

The buildpack downloads the SBT launcher and the ivy cache over HTTP using curl, and then doesn't perform any additional (hash, signature) validation:

heroku-buildpack-scala/lib/common.sh

Lines 165 to 172 in 4e3b004

	baseUrl="http://lang-jvm.s3.amazonaws.com/sbt/v8/sbt-cache"
	if [ -n "$playVersion" ]; then
	ivyCacheUrl="$baseUrl-play-${playVersion}_${scalaVersion}.tar.gz"
	else
	ivyCacheUrl="$baseUrl-base.tar.gz"
	fi
	curl --retry 3 --silent --max-time 60 --location $ivyCacheUrl | tar xzm -C $sbtUserHome

heroku-buildpack-scala/opt/sbt-extras.sh

Lines 83 to 86 in 37a9ba9

	0.7.*) echo "http://simple-build-tool.googlecode.com/files/sbt-launch-0.7.7.jar" ;;
	0.10.* ) echo "$sbt_launch_repo/org.scala-tools.sbt/sbt-launch/$version/sbt-launch.jar" ;;
	0.11.[12]) echo "$sbt_launch_repo/org.scala-tools.sbt/sbt-launch/$version/sbt-launch.jar" ;;
	*) echo "$sbt_launch_repo/org.scala-sbt/sbt-launch/$version/sbt-launch.jar" ;;

heroku-buildpack-scala/opt/sbt-extras.sh

Line 118 in 37a9ba9

declare sbt_launch_repo="http://repo.typesafe.com/typesafe/ivy-releases"

The AWS S3 bucket, repo.typesafe.com and simple-build-tool.googlecode.com all serve valid SSL certificates, so should be accessed over HTTPS.

Differentiate Play 2.0 apps

Change detect output to be 'Play 2.0 Java' or 'Play 2.0 Scala' depending on the main language in build.scala.

The Scala buildpack seems provision a legacy "Dev" plan postgres database

I just completed the Getting Started with Scala on Heroku tutorial. When I type heroku pg:info, I see that for my database, the postgres plan is "Dev", but I expected to see "Hobby-dev". I guess it's provisioning the "Dev" plan because in heroku-buildpack-scala/bin/release, the addons line says heroku-postgresql:dev.

I just started recently and I'm still getting familiar with everything, but I think the "Dev" postgres plan might be legacy now (https://devcenter.heroku.com/articles/heroku-postgres-legacy-plans)?

Maybe that line should say:
heroku-postgresql:hobby-dev
so that it uses the new "Hobby-dev" Postgres plan?

Play 2.3.2 Deploy Fails via Build API

I'm deploying a Play 2.3.2 app via the Build API (not git push). Here is the error:

----> Play 2.x - Java app detected
-----> Installing OpenJDK 1.6...done
-----> Running: sbt compile stage
       Getting org.scala-sbt sbt 0.13.5 ...
       :: retrieving :: org.scala-sbt#boot-app
        confs: [default]
        44 artifacts copied, 0 already retrieved (13482kB/237ms)
       Getting Scala 2.10.4 (for sbt)...
       :: retrieving :: org.scala-sbt#boot-scala
        confs: [default]
        5 artifacts copied, 0 already retrieved (24459kB/71ms)
       [info] Loading project definition from /tmp/scala_buildpack_build_dir/project
       [warn] Error loading JNotify watch service: /tmp/scala_buildpack_build_dir/target/native_libraries/64bits/libjnotify.so: /lib/libc.so.6: version `GLIBC_2.12' not found (required by /tmp/scala_buildpack_build_dir/target/native_libraries/64bits/libjnotify.so)
       java.lang.UnsatisfiedLinkError: /tmp/scala_buildpack_build_dir/target/native_libraries/64bits/libjnotify.so: /lib/libc.so.6: version `GLIBC_2.12' not found (required by /tmp/scala_buildpack_build_dir/target/native_libraries/64bits/libjnotify.so)
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1750)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1675)
        at java.lang.Runtime.loadLibrary0(Runtime.java:840)
        at java.lang.System.loadLibrary(System.java:1047)
        at net.contentobjects.jnotify.linux.JNotify_linux.<clinit>(Unknown Source)
        at net.contentobjects.jnotify.linux.JNotifyAdapterLinux.<init>(Unknown Source)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
        at java.lang.Class.newInstance0(Class.java:374)
        at java.lang.Class.newInstance(Class.java:327)
        at net.contentobjects.jnotify.JNotify.<clinit>(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at play.sbtplugin.run.JNotifyPlayWatchService$JNotifyDelegate.ensureLoaded(FileWatcher.scala:158)
        at play.sbtplugin.run.JNotifyPlayWatchService$$anonfun$5.apply(FileWatcher.scala:208)
        at play.sbtplugin.run.JNotifyPlayWatchService$$anonfun$5.apply(FileWatcher.scala:169)
        at scala.util.control.Exception$Catch$$anonfun$withTry$1.apply(Exception.scala:129)
        at scala.util.control.Exception$Catch$$anonfun$withTry$1.apply(Exception.scala:129)
        at scala.util.control.Exception$Catch.apply(Exception.scala:102)
        at scala.util.control.Exception$Catch.withTry(Exception.scala:129)
        at play.sbtplugin.run.JNotifyPlayWatchService$.apply(FileWatcher.scala:169)
        at play.sbtplugin.run.PlayWatchService$.default(FileWatcher.scala:61)
        at play.PlaySettings$$anonfun$defaultSettings$41.apply(PlaySettings.scala:180)
        at play.PlaySettings$$anonfun$defaultSettings$41.apply(PlaySettings.scala:180)
        at scala.Function1$$anonfun$compose$1.apply(Function1.scala:47)
        at sbt.EvaluateSettings$MixedNode.evaluate0(INode.scala:177)
        at sbt.EvaluateSettings$INode.evaluate(INode.scala:135)
        at sbt.EvaluateSettings$$anonfun$sbt$EvaluateSettings$$submitEvaluate$1.apply$mcV$sp(INode.scala:67)
        at sbt.EvaluateSettings.sbt$EvaluateSettings$$run0(INode.scala:76)
        at sbt.EvaluateSettings$$anon$3.run(INode.scala:72)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:679)
       [info] Set current project to play-java (in build file:/tmp/scala_buildpack_build_dir/)
       [success] Total time: 1 s, completed Jul 22, 2014 11:29:03 PM
       SLF4J: Class path contains multiple SLF4J bindings.
       SLF4J: Found binding in [jar:file:/tmp/scala_buildpack_build_dir/.sbt_home/.ivy2/cache/org.slf4j/slf4j-nop/jars/slf4j-nop-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
       SLF4J: Found binding in [jar:file:/tmp/scala_buildpack_build_dir/.sbt_home/.ivy2/cache/org.slf4j/slf4j-jdk14/jars/slf4j-jdk14-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
       SLF4J: Found binding in [jar:file:/tmp/scala_buildpack_build_dir/.sbt_home/.ivy2/cache/org.slf4j/slf4j-simple/jars/slf4j-simple-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
       SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
       SLF4J: Actual binding is of type [org.slf4j.helpers.NOPLoggerFactory]
       [info] Wrote /tmp/scala_buildpack_build_dir/target/scala-2.11/play-java_2.11-1.0-SNAPSHOT.pom
       [success] Total time: 1 s, completed Jul 22, 2014 11:29:04 PM
-----> Dropping ivy cache from the slug
-----> Dropping compilation artifacts from the slug
-----> Discovering process types
       Procfile declares types           -> (none)
       Default types for Play 2.x - Java -> web

-----> Compressing... done, 120.3MB
-----> Launching... done, v20
       http://agile-river-1605.herokuapp.com/ deployed to Heroku

Only keep the JARs in the ivy cache as indicated by the CP

hi All,

I am running a play2-mini application on Heroku and ran into the issue that the compiled slug size was too large. I see that this kind of issue has been resolved (#8 #10) for (non-mini) play applications. I am wondering if there might be an equally slick solution for those who are running play2-mini apps.

The current workaround I have in place is a modification of the buildpack to remove all JARs from the ivy cache which are not present on the classpath as given by the target/start script. I realize this is probably not an ideal solution, but it seems to fit the bill for the moment. If there are any alternative ideas, suggestions, or thoughts on a more general solution, that would be great!

Best,
-Eric

PS - Here is a gist of the relevant change I made to the buildpack.

Scala Official Buildpack Image

Adding PR.

SBT 0.12.4

Add support for SBT 0.12.4. It should have some memory fixes that may alleviate some of the pain of slow builds.

Build pack for Play 2.1-RC2 with FFMpeg

I see the custom build pack for Play 2.1-RC2. My Scala Play app also needs FFMpeg. Seems this pulls in lots of dependencies which causes the slug to be over-large. What approach should be taken? Here is what I have been able to find so far:

http://www.xuggle.com/xuggler/
https://github.com/dzello/ffmpeg-heroku/blob/master/README.md
http://pastebin.com/vejQqNek
http://stackoverflow.com/questions/1281353/use-java-ffmpeg-wrapper-or-simply-use-java-runtime-to-execute-ffmpeg

It would be great if such a build pack already existed, or I could modify a similar one to include the Play 2.1-RC2 changes.

Thanks,

Mike

Require.js compilation is slow on Heroku

Require.js compilation is slow and often causes build timeouts. It's been observed that build which are fast enough locally can take much longer when building on Heroku.

Export SBT for subsequent build packs

As in the title, it is very helpful if buildpacks run after this one have access to sbt.

Do not resolve tests for Heroku builds

Since tests are not run in bin/compile, there is no reason they need to be resolved and download. The approach of modifying allDependencies works locally by filtering in the HerokuPlugin; however, for some reason, the plugin is not being picked up on Heroku.

Multiple Scala Versions in Slug

If you have multiple Scala versions in your build cache, it ends up in your slug in .sbt_home/boot. Each version of Scala is over 35M and can increase slug size over time.

Example listing:

~/.sbt_home/boot $ du -h --max-depth=1
50M ./scala-2.10.3
38M ./scala-2.10.4
37M ./scala-2.10.2
123M    .

The .sbt_home/boot dir is added to the cache in bin/compile.

Consider SBT-Extras for Version Detection

Travis uses sbt-extras for sbt version detection and execution. It might make version detection less of a maintenance issue in the buildpack if that project were used instead of our own minimal detection scheme.

Future proof for Play

Play 2.3 now compiles/copies/processes assets in a directory structure in target/web. If there are many large assets, eg images, pdfs, other files, this can significantly increase slug size with junk, since these directories aren't removed. Also Play dumps a jar in target directly containing all assets (for deployment to a CDN for example). We've seen at least one app have its slug size blow up because these new files/directories aren't removed.

So, I'd like to talk about future proofing the scala buildpack for Play. I know very little about how build packs work for Heroku, which is why I haven't just prepared a pull request myself but wanted to talk about it first, but it seems that the following steps are done:

1. Build
2. Cache the build
3. Delete unnecessary files from the build
4. Copy the build back to where Heroku expects it

What if, for Play, the following was done:

1. Build
2. Cache the build
3. Move only target/universal to the place where Heroku expects it (probably also should move target/staged and target/start to maintain support for 2.0.x and 2.1.x)
4. Delete the whole build directory and ivy cache

If this was done, it would guarantee that only the files needed by Play are included in the slug, ensuring that anything else that Play puts in the target directory in future doesn't count, and also means that in multi project setups, where there are multiple target directories, these directories get cleaned up too.

The only place that I can think that this might cause a problem is for applications that rely on things outside of their dist artifact. This is very bad practice, and also easy to fix, by adding the additional files that they depend on to mappings in Universal. I'm not sure how/if Heroku deals with/allows breaking changes build packs, but I'm sure there are other solutions that we could come to if this stands in the way.

HerokuPlugin not being used by SBT

For some reason the HerokuPlugin, which gets loaded here is not actually being used by SBT. I have looked into this briefly and tried using $SBT_USER_HOME/.sbt/plugins, $SBT_USER_HOME/.sbt/0.13/plugins, and $HOME/.sbt/plugins, $HOME/.sbt/0.13/plugins, but no luck.

add sbt script back in

A short while back we stopped including the script to launch SBT in the slug of the app. This makes things like

heroku run sbt console

need to change to

heroku run 'java -jar .sbt_home/bin/sbt-launch-0.11.3-2.jar console'

It would be easier if the script were still there.

Play 2.4 application with disabled Play layout causes the slug size to exceed the maximum

In heroku-buildpack-scala/lib/common.sh the detection of the project is a Play-2.x application is done as follows:

_has_playConfig() {
  local ctxDir=$1
  test -e $ctxDir/conf/application.conf
}

But what if I want to use the default SBT layout? What if I use

lazy val root = (project in file("."))
  .enablePlugins(PlayScala)
  .disablePlugins(PlayLayoutPlugin)

This means that my application.conf is in the directory src/main/resources and not in conf.
And this has as a consequence that my slugsize on Heroku is getting to big and it will not build.

Bump JDK 8 to Latest

For this:
https://blog.codecentric.de/en/2014/08/string-deduplication-new-feature-java-8-update-20-2/

Push broken after commit 0900a919e2

Since commit 0900a91 was pushed, I get the following error when pushing to Heroku:

-----> Heroku receiving push
-----> Fetching custom buildpack... done
-----> Play 2.0 app detected
/tmp/buildpack_2urmw3yi3m00s/bin/compile: line 8: bin/common: No such file or directory
! Heroku push rejected, failed to compile Play 2.0 app

No access to commands from previous buildpacks

Hi,

I try to deploy a Play Yeoman application to heroku. I use the heroku-buildpack-multi and my .buildbacks file looks as follows:

https://github.com/heroku/heroku-buildpack-ruby.git
https://github.com/heroku/heroku-buildpack-nodejs.git
https://github.com/heroku/heroku-buildpack-scala.git

The first two buildpacks will be executed successful. The third buildpack fails with the message:

Will run: [grunt, --gruntfile=Gruntfile.js] in /tmp/scala_buildpack_build_dir/ui
   java.io.IOException: Cannot run program "grunt" (in directory "/tmp/scala_buildpack_build_dir/ui"): error=2, No such file or directory

In my project there exists a package.json which looks as follows:

{
  "name": "play-silhouette-angular-seed",
  "version": "0.0.0",
  "dependencies": {
    "grunt-cli": "~0.1.13",
    "grunt": "~0.4.5",
    "bower": "~1.3.12",
    "yo":  "~1.3.3"
  },
  "engines": {
    "node": "0.10.x"
  }
}

All the node components will be installed during the build process. If I remove the scala buildpack then I can see the node_modules folder. The bin folder inside the node_modules folder is also in the path and I can run the grunt command from the bash.

The problem is now that the scala buildpack has no access to the grunt command. But why?

Best regards,
Christian

sbt 0.13.1

support sbt-coursier

https://github.com/alexarchambault/coursier/ - a faster dependency engine pluggable into sbt
this probably means just adding caching for ~/.coursier

Timeouts during deploy

I can't get my app deployed to heroku since it hits the timeout limit of 900 seconds. The "Getting org.scala-sbt sbt 0.12.2"-step (no. 2) takes a really long time... Is there something that can be done to get around that?

cannot download sbt

remote:        Downloading sbt launcher for 0.13.9-M1:        
remote:          From  http://typesafe.artifactoryonline.com/typesafe/ivy-releases/org.scala-sbt/sbt-launch/0.13.9-M1/sbt-launch.jar        
remote:            To  /tmp/scala_buildpack_build_dir/.sbt_home/launchers/0.13.9-M1/sbt-launch.jar        
remote:        Download failed. Obtain the jar manually and place it at /tmp/scala_buildpack_build_dir/.sbt_home/launchers/0.13.9-M1/sbt-launch.jar        
remote: 
remote:  !     ERROR: Failed to run sbt!        
remote:        We're sorry this build is failing! If you can't find the issue in application        
remote:        code, please submit a ticket so we can help: https://help.heroku.com        
remote:        You can also try reverting to our legacy Scala buildpack:        
remote:        $ heroku buildpacks:set https://github.com/heroku/heroku-buildpack-scala#legacy        
remote:                
remote:        Thanks,        
remote:        Heroku        
remote: 
remote: 
remote:  !     Push rejected, failed to compile Scala app        

it appears that your launcher uses wrong repository, it should be using repo.typesafe.com afaik
also note that 'heroku buildpacks' ' is not a heroku command.'
btw is there a way to use a launcher from my the project repo?

git push hangs after packaging is done

   [info] Done packaging.
   [info] Done packaging.
   !     Timed out compiling Play 2.x - Scala app (15 minutes)
   !     See https://devcenter.heroku.com/articles/slug-compiler#time-limit

Play framework 2

After reading several docs, I still fail to deploy a Play2 app to heroku.
App is https://github.com/cchantep/acolyte/tree/play-demo and error at push is:

-----> Scala app detected
-----> Installing OpenJDK 1.6...done
 !      Error, your scala project must include project/build.properties and define sbt.version
 !      You must use a release verison of sbt, sbt.version=0.11.0 or greater

 !     Push rejected, failed to compile Scala app

To [email protected]:acolyte-play-demo.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to '[email protected]:acolyte-play-demo.git'

Local sbt clean compile stage is sucessful, so cause is quite unclear to me.

Compilation error when moving controller to non-default location "controllers"

We have a play application that compiles fine on our local machine. On heroku it fails with following error:

-----> Play 2.x - Java app detected
-----> Installing OpenJDK 1.7...done
-----> Running: sbt compile stage
[info] Loading project definition from /tmp/scala_buildpack_build_dir/project
[warn] Multiple resolvers having different access mechanism configured with same name 'typesafe-ivy-releases'. To avoid conflict, Remove duplicate project resolvers (resolvers) or rename publishing resolver (publishTo).
[info] Set current project to .... (in build file:/tmp/scala_buildpack_build_dir/)
[info] Compiling 2 Scala sources and 81 Java sources to /tmp/scala_buildpack_build_dir/target/scala-2.10/classes...
[error] /tmp/scala_buildpack_build_dir/target/scala-2.10/src_managed/main/controllers/routes.java:8: error: cannot find symbol
[error] public static final controllers.ReversePreviews Previews = new controllers.ReversePreviews();
[error] ^
[error] symbol: class ReversePreviews
[error] location: package controllers
[error] /tmp/scala_buildpack_build_dir/target/scala-2.10/src_managed/main/controllers/routes.java:9: error: cannot find symbol
[error] public static final controllers.ReverseUsers Users = new controllers.ReverseUsers();

It seems it is expecting the controllers in the standard "app/controllers" package. Since Play 2.x it is however possible to move the controllers to any package.

Is there a workaround?

Deployment to heroku error

I get this error when deploying my play app to heroku

[info] Set current project to scala_buildpack_build_dir (in build file:/tmp/scala_buildpack_build_dir/)
[info] Updating {file:/tmp/scala_buildpack_build_dir/}scala_buildpack_build_dir...
[info] Resolving org.scala-lang#scala-library;2.10.4 ...
[info] Resolving org.scala-lang#scala-compiler;2.10.4 ...
[info] Resolving org.scala-lang#scala-reflect;2.10.4 ...
[info] Resolving org.scala-lang#jline;2.10.4 ...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[success] Total time: 0 s, completed Aug 4, 2014 9:15:25 PM
[error] Not a valid command: stage (similar: last-grep, set, last)
[error] Not a valid project ID: stage
[error] Expected ':' (if selecting a configuration)
[error] Not a valid key: stage (similar: state, target, tags)
[error] stage
[error] ^
! Failed to build app with sbt

! Push rejected, failed to compile Play 2.x - Java app

Allow project to be in a sub-dir

See:
https://groups.google.com/d/msg/play-framework/f-V_bIYAwYw/5CI520WqSDEJ

Skip source download

There is no need to include source dependencies:

[info] Packaging 
/tmp/build_1m8od6mu7tnkv/target/scala-2.10/mocc_2.10-0.1.0-sources.jar ..

Detect Play applications in sub-dirs

The Play app detection only looks in the root dir, which does not handled nested Play applications.

cleancache branch not up to date

I tried to run a cache-cleaning build for a Play 2.2 application and it fails because the branch isn't up to date with master and doesn't support sbt 0.13.