Thanks for the clarification.I've pushed the in-place compilation code to master (which is still 4.0.x) so now in 4.0 to update the .css files you can just run "mvn sass:update-stylesheets -pl uportal-war"
To watch a SCSS template and have the plugin write the CSS to tomcat you can run "mvn sass:watch -pl uportal-war -Dwatch.output=/Users/edalquist/java/tomcat/apache-tomcat-6.0.32-UP3t/webapps/uPortal/ -Dwatch.skin=uportal3" changing the output path to your tomcat/uportal deployment.
I'll make the changes that I believe need to be made for build time SCSS->CSS generation (for 4.1) on a branch and post a link here for folks to review when I'm done.
-Eric On 5/10/12 11:58 AM, Peter Hart wrote:
Eric: 1. I did not touch muniversality. I might be able to get to that today.2. skin.xml shouldn't need to change since at startup all the portal.css files will be in the same place as before (right?).3. The only .css files that can be deleted are the portal.css files in universality. These are the only files currently built with SASS.*Peter J. Hart* User Experience unicon.net ------------------------------------------------------------------------ *From: *"Eric Dalquist" <[email protected]> *To: *[email protected] *Sent: *Wednesday, May 9, 2012 7:28:38 PM *Subject: *Re: [uportal-dev] sass-maven-plugin I need some clarification for the 4.1 work. I deleted 7 portal.css files: https://github.com/Jasig/uPortal/commit/d0f6070aaede0493c71768542ce1305bdfc66098 There are six scss directories: uportal-war/src/main/webapp/media/skins/muniversality/common/scss uportal-war/src/main/webapp/media/skins/universality/coal/scss uportal-war/src/main/webapp/media/skins/universality/common/scss uportal-war/src/main/webapp/media/skins/universality/hc/scss uportal-war/src/main/webapp/media/skins/universality/ivy/scss uportal-war/src/main/webapp/media/skins/universality/uportal3/scssWhen I run scss update_stylesheets on those six directories I get five .css files./media/skins/muniversality/common/portal.css ./media/skins/universality/coal/portal.css ./media/skins/universality/hc/portal.css ./media/skins/universality/ivy/portal.css ./media/skins/universality/uportal3/portal.css So for the questions: 1. Should I have deleted uportal-war/src/main/webapp/media/skins/muniversality/common/scss/portal.css 2. Are there any changes to the skin.xml files that will be needed? 3. Are there any orphaned .css files in places (like uportal-war/src/main/webapp/media/skins/universality/common/css/) that can/should be deleted? -Eric On 5/3/12 10:48 AM, Gary Thompson wrote: Eric, Yay! Thanks for completing that work. I agree that it should be merged into master and add the documentation you listed. I can contribute to #1-4. I also agree that it feels like a 4.1 change. Just so that everyone is aware, SCSS will accept any valid CSS syntax. So if people want to still author in CSS, it can be added to the SCSS files. This is true for both uPortal development as well as institution custom skins. Ideally, people would uptake the benefits of SCSS, but "plain" CSS is still valid within SCSS. -Gary On Apr 30, 2012, at 2:34 PM, Eric Dalquist wrote: Luckily the resource aggregation plugin required no work and we have the build time SCSS -> CSS compilation working in the UP-3456 branch. I'm thinking we should get this merged into master and then do the following in the manual: 1. Document a recommended best practice for custom skin development of copying one of the provided skin directories and then customizing. Deployers should be discouraged from modifying any of the provided skins in place. 2. Suggest (a lighter statement than recommend) that deployers avoid modifying css/js files in the "common" directory and instead override styles in their skin specific CSS. 3. Document how to generate/capture the CSS output from the SCSS template for a custom skin if the deployer would rather use CSS instead of SCSS 4. Document how to use the SASS Watch utility to do CSS development for a custom skin. I'm thinking that it would be valuable to consider adding the watch functionality to the sass-maven-plugin since we'll be adding documentation for that use of the tool. The last question is where do we do this? Is deleting the shipped CSS files a big enough change that this should only happen for 4.1? I'm thinking that is the case since deleting the .css files could be problematic for folks that have customized one of the provided skins. -Eric On 4/30/12 10:24 AM, Jen Bourey wrote: 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 [email protected] as:[email protected] To unsubscribe, change settings or access archives, seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev--You are currently subscribed [email protected] as:[email protected] To unsubscribe, change settings or access archives, seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
smime.p7s
Description: S/MIME Cryptographic Signature
