Re: [uportal-dev] sass-maven-plugin

[Eric Dalquist]

Jen pointed out that I was using the default style, changed it to ": expanded" and the SASS matches the CSS! So issue 1 has been addressed.

The only question is what do we do about the SCSS vs CSS files.

-Eric

On 4/30/12 8:59 AM, Eric Dalquist wrote:

I have a snapshot of a sass compiling maven plugin deployed, the source is here: https://github.com/Jasig/sass-maven-plugin

I've created a branch of uPortal to figure out how we move forward with this: https://github.com/Jasig/uPortal/tree/UP-3456

*Issue 1:*

When I generated the CSS files from the SASS templates the resulting CSS didn't match what was already in git. You can see the diffs here: https://github.com/Jasig/uPortal/commit/9256edc359e9face91d98f2fa190b3cd9114f3b7

*Issue 2*






-Eric


Ruby script as generated by the plugin:
require 'rubygems'
require 'sass/plugin'
Sass::Plugin.options.merge!(
    :cache_location => 'uportal-war/target/sass_cache',
    :cache => true,
    :unix_newlines => true,
    :always_update => true
)

Sass::Plugin.update_stylesheets

It looks like most of the changes are formatting, I'm wondering if there is something I need to change in the generated ruby script that compiles the templates or the version of SASS being used. The only existing maven artifact for SASS I could find is 3.1.15 though that only appears to be a point release behind the current version. I've pasted the script at the bottom of this email. What is our long term project config goal. Do we want both the SCSS and CSS files in git and we just use the mvn task to re-generate them when needed? Or do we remove the CSS files from git and generate them at build time using the mvn task? For option 1 the advantage is that deployers don't need to learn SCSS/SASS the CSS files are there for them to use and just work. The downside is that we have to remember to only update the SCSS files during uPortal development and to regenerate the CSS files as needed. For option 2 the advantage is we remove what is effectively generate code form the git repo and never have to worry about the CSS being out of date. On the down side if deployers want to use CSS and non SCSS they need to copy the generated files back into the source tree and disable the SCSS plugin. This is doable but we would need to document it VERY WELL. Sass::Plugin.add_template_location('uportal-war/src/main/webapp/media/skins/muniversality/common/scss', 'uportal-war/src/main/webapp/media/skins/muniversality/common') Sass::Plugin.add_template_location('uportal-war/src/main/webapp/media/skins/universality/coal/scss', 'uportal-war/src/main/webapp/media/skins/universality/coal') Sass::Plugin.add_template_location('uportal-war/src/main/webapp/media/skins/universality/common/scss', 'uportal-war/src/main/webapp/media/skins/universality/common') Sass::Plugin.add_template_location('uportal-war/src/main/webapp/media/skins/universality/hc/scss', 'uportal-war/src/main/webapp/media/skins/universality/hc') Sass::Plugin.add_template_location('uportal-war/src/main/webapp/media/skins/universality/ivy/scss', 'uportal-war/src/main/webapp/media/skins/universality/ivy') Sass::Plugin.add_template_location('uportal-war/src/main/webapp/media/skins/universality/uportal3/scss', 'uportal-war/src/main/webapp/media/skins/universality/uportal3')

smime.p7s
Description: S/MIME Cryptographic Signature