shadowfiend / sbt-resource-management Goto Github PK

Hey,

I followed the install readme, running the 1.2 and master versions and also did a publish-local to get a 1.3-SNAPSHOT (on the offchance that some other result ended up happening) but I always end up getting "Expected end of input" trying to run any command with "resources:{command}".

running scala 2.9.1 and sbt 0.11.3-2

Not sure what other info to give that would be of use up front.

If src/main/webapp/stylesheets does not exist, everything goes up in smoke because we try to .head a Nil.

Expected Result:
Running ~ resources:copy-scripts should watch for changes to any JS or CS files, compile them, and copy them to the target directory.

Actual Result
Only changing CS files triggers a recompilation. Saving JS files does nothing. :'(

Hi there,

As most of y'all know, here at Elemica we use sbt-resource-management. Trick is, we want to upgrade to the latest sbt (1.3.9) and right now have to figure out whether to update sbt-resource-management or, well, do something else.

For some reason I have a note that links to this project but says "better to use grunt instead of rewrite sbt-resource-management". Sadly, I didn't write down why we should use grunt.

Any ideas or suggestions here?

Part of me thinks that we should update sbt-resource-management to sbt 1.3.9 because it's what we're currently using. It's how our markup connects to JavaScript and CSS ergo, moving away from sbt-resource-management implies quite a bit of work (like reworking of all of our markup).

On the other hand, maybe the aforementioned reworking is worth it. Heck, maybe one of y'all are the ones who suggested using grunt instead.

I figured I'd check in before starting The Production™️ :)

Thanks!

Currently having an issue (similar to a previous closed issue, but rebooting does nothing) where I am getting the following error:

all> resources:compile-sass
[error] Expected end of input.
[error] resources:compile-sass
[error]

Any ideas what would be causing this?

While tossing around ideas about how to improve pulling in external libraries when using sbt-resource-management, we came up with the idea of referencing libraries by URL in the bundle file. Such as:

base
http://code.jquery.com/jquery-2.1.3.min.js
my-thing.js

When copying scripts, sbt-resource-management would fetch jquery-2.1.3.min.js and stick it in the target JS folder which is, in theory, outside of source control. This prevents the need to manually download an external script into source control in your project.

This is a real issue.

Hey there,
I ran into a weird problem earlier today using Lift 2.5.0-SNAPSHOT & Scala 2.10

It turns out that if the lift:style-bundle / lift:script-bundle tags do not have a body (e.g. <lift:style-bundle name="base" /> ), templating will be stopped after the first such call to your snippet.

First of all, thanks for publishing this. I've been working on something that would be similar to this (I was basing it on Jammit), but haven't gotten very far into it and I think I'll just use this instead.

However, there is one small thing I'd like to address: some proxies don't cache items with a query string. Quoting google in the recommendations section:

Don't include a query string in the URL for static resources.
Most proxies, most notably Squid up through version 3.0, do not cache resources with a "?" in their URL even if a Cache-> control: public header is present in the response. To enable proxy caching for these resources, remove query strings from references to static resources, and instead encode the parameters into the file names themselves.

Basically, you need to rename the file instead of using a query string for it to be cached when behind one of those proxies. This probably represents a small number of users, but it may still be worth addressing.

What are your thoughts on this?

Trying to get up and running I've come across a couple of issues.

The breaker right now is:

[error] References to undefined settings:
[error]
[error] *:aws-s3-bucket from resources:compile-sass
[error]
[error] *:aws-access-key from resources:deploy-scripts
[error]
[error] *:aws-secret-key from resources:deploy-scripts
[error]
[error] *:aws-s3-bucket from resources:deploy-scripts
[error]
[error] *:aws-access-key from resources:deploy-styles
[error]
[error] *:aws-secret-key from resources:deploy-styles
[error]
[error] *:aws-s3-bucket from resources:deploy-styles

trying to boot from my project with default plugin settings.

The second is I can't figure out how you go about overriding the default paths as the syntax seems to be different to other plugins I've used in the path that follow the:

(scriptDirectories in ResourceCompile) <<= (webappResources in Compile) {
_ / "webapp" / "res" / "app" / "lib"
}

type notation

Thanks

Provided that you have two folders, coffeescript-root where your coffee scripts are located and javascript-root where the compiled JS files are sent, if you stick your coffee script file in coffeescript-root/a/awesome.coffee it is placed in javascript-root/awesome.js.

We should, instead, properly place things in correctly named subdirectories. So in the example above, awesome.js should have a path of javascript-root/a/awesome.js.

It would seem that running sbt ~resources:copy-scripts will watch coffeescript sources, but won't watch javascript sources - meaning that I have to restart the plugin each time I make a change to a javascript file in the source path.

Hey there,

when running an app using this plugin in development mode, the compiled coffeescript sources aren't available as they only live in the target/javascripts and target/compiled-coffee-script folders.

Would be great if you could fix this!

Three new lines throws the bundles for a loop. this should just squash to two new lines and move on

On line 190 it says

sbt resources:deploy-css

Should instead say:

sbt resources:deploy-styles

Currently the only way to do a Sass compile is by force. We need the ability to choose if we want to be forceful or not.

It would be useful to have the concept of bundle mixins, like you would with SASS. I don't know if these should have a special designation so that they don't exist as their own bundle, or if they should be a bundle in their own right. Either way, it would be very, very useful.