Re: [uportal-dev] sass-maven-plugin
I have the 4.1 compile SCSS at build time version of the plugin config setup here: https://github.com/jasig/uPortal/tree/UP-3456 I tested it locally and it works but I would really appreciate another set of eyes on it before I merge it back into master an make master 4.1 The sass:watch command hasn't changed but explicitly calling sass:update-stylesheets isn't needed. The plugin configuration will automatically build the scss files before packaging up the WAR. -Eric On 5/11/12 5:10 PM, Eric Dalquist wrote: 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 eric.dalqu...@doit.wisc.edu *To: *uportal-dev@lists.ja-sig.org *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/scss When 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
Re: [uportal-dev] sass-maven-plugin
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 - Original Message - From: Eric Dalquist eric.dalqu...@doit.wisc.edu To: uportal-dev@lists.ja-sig.org 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/scss When 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
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/scss When 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
Re: [uportal-dev] sass-maven-plugin
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:
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.
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.
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
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')
Re: [uportal-dev] sass-maven-plugin
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 to uportal-dev@lists.ja-sig.org as:
eric.dalqu...@doit.wisc.edu
To unsubscribe,
