(I'm sorry this is so vague.)

We have a Play application with about 20 files of scss source files that are compiled to css with play-sass. Everything is fine initially, but after maybe an hour of working with the templates the compiling stops. Play-sass just does not do anything anymore. Play still outputs a line of text, as I edit an scss file and save it, but the sass compilation does not seem to start.

We moved to using command line sass so that it watches the files and that seems to work well. However, it would be nicer to not need a separate shell window for the command line sass.

I'm sorry I don't really have enough details for you to fix this, but if you can suggest something I could try to get more info I'll definately try to do that! The problem is that play-sass works for so long that reproducing isn't very easy.

Thank you.

Thanks for the plugin!
I am fairly new to scala and play 2 so I apologize if there is an obvious answer to the following questions:

How to I set additional options for the sass compiler?

I tried the following but the options don't seem to get picked up by the compiler

import net.litola.SassPlugin
import net.litola.SassPlugin._

object ApplicationBuild extends Build {

val main = PlayProject(appName, appVersion, appDependencies, mainLang = SCALA).settings(
      // Add your own project settings here
           sassOptions := Seq("--compass","-r", "zurb-foundation")
    )

I would appreciate any hint.

Thanks for your effort!
cheers
syfl

Hi,

When using the sass plugin with the latest version of Play the following exception is thrown:

java.lang.NoSuchMethodError: sbt.SettingKey$.apply(Ljava/lang/String;Ljava/lang/String;Lscala/reflect/Manifest;)Lsbt/SettingKey;
    at net.litola.SassPlugin$.<init>(SassPlugin.scala:8)
    at net.litola.SassPlugin$.<clinit>(SassPlugin.scala)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:247)
    at sbt.ModuleUtilities$.getObject(ModuleUtilities.scala:10)
    at sbt.Load$.loadPlugin(Load.scala:586)
    at sbt.Load$$anonfun$loadPlugins$1.apply(Load.scala:583)
    at sbt.Load$$anonfun$loadPlugins$1.apply(Load.scala:583)
    at scala.collection.immutable.Stream$$anonfun$map$1.apply(Stream.scala:376)
    at scala.collection.immutable.Stream$$anonfun$map$1.apply(Stream.scala:376)
    at scala.collection.immutable.Stream$Cons.tail(Stream.scala:1060)
    at scala.collection.immutable.Stream$Cons.tail(Stream.scala:1052)
    at scala.collection.immutable.Stream.flatMap(Stream.scala:441)
    at sbt.Load$$anonfun$pluginGlobalSettings$1.apply(Load.scala:222)
    at sbt.Load$$anonfun$pluginGlobalSettings$1.apply(Load.scala:221)
    at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(TraversableLike.scala:239)
    at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(TraversableLike.scala:239)

Seems to be related to the change in SBT version.

i.e. for non-play "database" module, I get:

[error] database/*:playRequireJs from database/compile:resourceGenerators ((net.litola.SassPlugin.autoImport) SassPlugin.scala:31)

I've added the sass repo:

// sass repo
resolvers in ThisBuild += "Sonatype OSS Releases" at "https://oss.sonatype.org/content/repositories/releases"

and in my plugins:

// sass
addSbtPlugin("net.litola" % "play-sass" % "0.4.0")

Previously I setup the sbt-jasmine-plugin in my play 2.1 project it is working properly. Now I want to add SassPlugin. Everythime I get this error:

[error] /Users/orlybg/BTS/foo/bar/project/Build.scala:22: not found: value SassPlugin

My Build.scala is like this:

...
import com.joescii.SbtJasminePlugin._
import net.litola.SassPlugin._

.
.
.

lazy val main = play.Project(appName, appVersion, appDependencies)
.settings( SassPlugin.sassSettings:* )
.settings(appSettings:*)

  lazy val appSettings = jasmineSettings ++ seq(
    resolvers += "SBT community repo" at "http://dl.bintray.com/sbt/sbt-plugin-releases/",
    // jasmine configuration
    appJsDir               <+= baseDirectory / "app/public/javascripts",
    appJsLibDir            <+= baseDirectory / "app/public/javascripts/vendor",
    jasmineTestDir         <+= baseDirectory / "test/assets",
    jasmineConfFile        <+= baseDirectory / "test/assets/test.dependencies.js",
    jasmineRequireJsFile   <+= baseDirectory / "public/javascripts/vendor/require-2.0.6.js",
    jasmineRequireConfFile <+= baseDirectory / "test/assets/require.conf.js",

    // link jasmine to the standard 'sbt test' action.
    // Now when running 'test' jasmine tests will be run
    // and after that other Play tests will be executed.
    (test in Test) <<= (test in Test) dependsOn (jasmine)
)

}

What I'm missing here? any other configuration?

I always run

sbt update

and I have done

mvn -DskipTests=true clean package

and seems the plugin never get downloaded.

On windows, I managed to make the plugin work.

However if I start the play server (run) , and after i make any change to the scss, after refreshing the page the changes are not taken.

I have to stop sbt, delete the target and .sass-cache folder and restart sbt. Only then will the plugin recompile the styles.

This is very cumbersome and it is impossible to be any productive like this, have you guys experienced the same issue?

Where I @extend a style with some background image, like

.someStyle {
background-image: url(images/bg.jpg);
}

.myStyle{
@extend .someStyle;
}

it does not compile until it finds images/bg.jpg The problem is that when compiling it searchers relatively to project directory (not in "assets" or "public"as it should be), so to make it compile I have to either copy images to myplayapp/images or try to avoid inheriting from something with any background

I am trying to use it with compass+susy+zurb-foundation but it thorws errors when I import foundation or susy ( http://susy.oddbird.net/ ) to sccs.

I use net.litola.SassPlugin.sassOptions := Seq("--compass", "-r", "compass", "-r", "zurb-foundation")

and it does not seem to work even for foundation

I think it is because I do not know how to configure play-sass right and because I am new to compass (I used to use LESS before and now switched to sass-comnpass as it is better), please provide detail explanation about compass configuration in play-sass

I'm using 0.2.0 version of plugin for play 2.1.1. I have a problem with dependencies. My scss files are organized in following way:

main.scss
dep1.scss
dep2.scss

main.css file is included in html.

Whenever I change something in dep1.scss it gets compiled but what I really need is main.scss to be recompiled since this scss file produces css stylesheet that is included in html.

I there any way around that? Maybe this problem is fixed in newer version of plugin (for play 2.3)?

Currently breaks the build on Play 2.4.0 with the following error:

java.lang.NoClassDefFoundError: play/PlayAssetsCompiler

That would be awesome. Is that something that is feasible?

I have created a sample project at https://github.com/brbrown25/play2.1Sass
I would like to have this configured so that I launch my play app, and any changes to my sass files trigger recompilation. I have a config.rb file so that compass settings can be configured. any help would be greatly appreciated. thanks!

Is it possible to have compilation in runtime?

Rudolf

Play supports Webjars to manage web library dependencies (like zurb foundation). It would be nice if the play-sass plugin supported the import of webjar files into .scss files.

I use https://github.com/doabit/semantic-ui-sass and I have to copy its parts (esp. images and fonts) to the root of my app (i.e. myapp/images/semantic-ui and myapp/fonts/semantic-ui) because I cannot configure Play-Sass (and compass in particular) from where to take them
That is why it would be great to see both better play-sass configuration as well as some docs

I am currently in the process of handing play-stylus over to my employer’s account, @patiencelabs. As part of the transfer I am also going to publish the latest version of play-stylus to our package repository to allow people using the plugin to properly cache the artifact in their repository proxy.

We actually switched to Sass a while ago ourselves, though, and are now using your plugin. (I was so pleased to find your plugin when contemplating the switch!) So I would be interested in giving play-sass the same treatment for more standard dependency management.

Do you have any intention to publish it to a repository of your own, Sonatype, or another central repository?

sbt has a guide for publishing to Sonatype. I would be interested in working on this, too, in case it doesn’t fit your roadmap.

Heya, thanks for the plugin.

I need to support development on windows and I used your plugin which at least worked great on a mac but it explodes on windows.

Seems to be an issue with ProcessBuilder not being able find "sass.bat" when the command given is "sass".
I forked and tried replaced "sass" with "sass.bat" and it started working on windows.

I just hopped into scala/play/sbt so I don't dare making the fix myself (yet) but it'd be cool if it'd check OS for the correct command , or maybe just make the command itself configurable.

import net.litola.SassPlugin
......
lazy val main = Project(
        appName, file(".")
    ).enablePlugins(play.PlayJava, net.litola.SassPlugin).settings(
            resolvers += Resolver.sonatypeRepo("releases"),
            resolvers += Resolver.url("Objectify Play Repository", url("http://schaloner.github.com/releases/"))(Resolver.ivyStylePatterns),
            resolvers += Resolver.url("Objectify Play Snapshot Repository", url("http://schaloner.github.com/snapshots/"))(Resolver.ivyStylePatterns),
            resolvers += Resolver.url("typesafe", url("http://repo.typesafe.com/typesafe/repo")),
            resolvers += Resolver.url("typesafe-releases", url("http://repo.typesafe.com/typesafe/maven-releases")),
            resolvers += Resolver.url("sbt-plugin-snapshots", new URL("http://repo.scala-sbt.org/scalasbt/sbt-plugin-snapshots/"))(Resolver.ivyStylePatterns),
            resolvers += Resolver.url("sbt-plugin-releases",  new URL("http://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/"))(Resolver.ivyStylePatterns),
            resolvers += "ReactiveCouchbase" at "https://raw.github.com/ReactiveCouchbase/repository/master/snapshots",
            resolvers += Resolver.sonatypeRepo("snapshots"),
            scalaVersion := "2.11.1",
            sassOptions := Seq("--compass"),
            libraryDependencies ++= appDependencies        
    )

[info] Loading project definition from /Users/kirill-laptop/workspace/explain-project-git/project
[error] /Users/kirill-laptop/workspace/explain-project-git/project/Build.scala:53: not found: value sassOptions
[error] sassOptions := Seq("--compass"),
[error] ^
[error] one error found
error Compilation failed

Doesn't work for me :(

It would be good for the sass executable/path to be configurable, e.g. to use bundle exec or a Bundle-installed bin stub.

Thanks for this awesome plugin.

But I have some issue to use compass with the --compass option.

name := """XXXXXXX"""

version := "1.0-SNAPSHOT"

lazy val root = (project in file(".")).enablePlugins(PlayJava, net.litola.SassPlugin)
  .settings(
    sassOptions := Seq("--compass")
  )

scalaVersion := "2.11.1"

libraryDependencies ++= Seq(
  javaJdbc,
  javaEbean,
  cache,
  javaWs
)

My scss files are compiled but not with compass.
Is it a real issue or just me ?

In Play 2.1.0's Build.scala I had to set the settings like

val main = play.Project(appName, appVersion, appDependencies).settings(
  // ...
  SassPlugin.sassSettings(0),
  SassPlugin.sassOptions := Seq("--compass","-r", "compass", "-r", "zurb-foundation"),
  SassPlugin.sassSettings(2)
)

(sassOptions specific to my setup but you get the point) since SassPlugin.sassSettings:_* doesn't work. Is there any more elegant way of doing that?

You might also want to update the README.

I have 2 scss file /app/assets/stylesheets/main.scss and /app/assets/stylesheets/main2.scss. If I edit main.scss and then refresh /assets/stylesheets/main.css in the browsers I get a 200 but if I refresh for /assets/stylesheets/main2.css I get a 404. The opposite happens if I change main2.scss, I can then load main2.css but main.css is not longer available. Under /target/scala-2.9.1/resource_managed/main/public/stylesheets both files reside but under /target/scala-2.9.1/classes/public/stylesheets only the changed file resides. So if I change main.scss only main.css will be listed under /target/scala-2.9.1/classes/public/stylesheets and if I then change main2.scss, main.css is replaced with main2.css. It seems the resource_managed directory should be the directory where the css files should be pulled from but I think they are getting pulled from the classes directory.

Instead of requiring a local installation of sass, embed the sass compiler using JRuby. Perhaps this project https://github.com/darrinholst/sass-java already solves this matter.

After I updated to the latest compass and sass I started getting play.PlayExceptions$AssetCompilationException: Compilation error[Sass compiler: WARNING: The compass/css3/shared module has been deprecated.]
It would be nice to see configuration sample set up for latest sass/compass

I am trying to run it with Play Framework 2.2.0RC1
Unfortunately Sonatype releases search for scala 2.10 does not find any play-sass 0.2.0 Please add Scala 2.10 version to repository!

It would be nice if you provide a sample of the code that uses libsaas as more and more people move to libsaas due to bad performance of ruby

Hi there!

I actually started using https://github.com/ShaggyYeti/sbt-sass a couple days ago and was able to add sourcemap support (see my pull request: ShaggyYeti/sbt-sass#10).

Once I realized this other project was more-or-less a clone copy of this one, I thought I'd give it a shot here too! Unfortunately I haven't been able to quite grok how this should work with the way you have things set up here, so I thought I'd just file an issue instead.

Mainly, it seems like the play.AssetsCompiler trait, which I've been unable to find docs/source for, is doing something with the generated files to either move them or write them or I'm not sure what's going on here. For sourcemaps in sass, you need to explicitly specify the infile path and the outfile path.

Anyway, I'm happy to attempt this again if I can get some guidance. Otherwise, perhaps my PR to sbt-sass will be enough for you to work from.

Adding the following

play.Project.playScalaSettings ++ SassPlugin.sassSettings

to build.sbt causes problems with the test:fork setting in sbt. If you try to set forking to false in build.sbt like so

Keys.fork in (Test,test) := false

or

Keys.fork in Test := false

Test:fork will abide by the setting, but test:fork will not. It will always be true and the JVM will fork on tests. Run show test:fork from the Play console to see.

The fix seems to simply be to add the sass settings without the playScalaSettings. That is just add the following to build.sbt,

SassPlugin.sassSettings

In the old days, SASS only worked with Ruby, but there is now a reference SASS implementation as a C library (called Libsass). Because of this, many other languages are able to support SASS, including Java through Jna.

There is a libsass-maven-plugin (https://github.com/warmuuh/libsass-maven-plugin) which is a Java wrapper around libsass.

It would be more ideal if play-sass used libsass instead of having to rely on sass being available on path, this would provide many benefits

• More guarantees on correctness (can fix libsass versions, and can use specific libsass versions if there are known versions that cause problems)
• Speed/Performance. The reference libsass is implemented in C, so it should offer superior performance compared to the ruby version
• (Possible) Better cross platform support. The libsass-maven-plugin provides dynamic libraries for linux64/mac OSX/windows, although its possible to add more platforms by compiling our own binaries and adding them to -Djna.library.path (or we can just make a pull request for additional builds with other platforms). Although people can argue that Ruby is also cross platform, setting up Ruby deterministically in separate environments is much harder than just supplying built dynamic libraries
• Much easier to work with build tools/deployment issues (building on from the previous point). Assuming your server is using the one of the supported OS's, you don't need to do the whole hoopla of setting up RUBY/working with $PATH variables, etc etc.

Definitely willing to make a pull request to implement this, assuming there are no real objections