My personal thought is that we take option 2 and write clear instructions in the manual for disabling the SCSS build. We probably also want to document how to disable it on a skin-specific basis - probably the most likely need is to know how to let the portal continue using the default behavior for the built-in skins, but create university-specific skins that don't use SCSS.
- Jen On Apr 30, 2012, at 6: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 > > 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. > > Issue 2 > 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. > > -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.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') > Sass::Plugin.update_stylesheets > -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
