Well, we might consider executing the minification programatically as well if that would help. I think it actually might make sense if what we did was provide a standard location where javascript and css files could be added such that they would automatically be loaded and compiled into any views for that particular module (i.e. src/main/assets or src/main/webapp/assets or src/main/webapp/WEB-INF/assets maybe?) . This is how a lot of other convention-based frameworks work and is something which saves time for developers because they really don't have to do anything manually to enable all of this behavior.
See the asset pipeline for Ruby on Rails:
http://guides.rubyonrails.org/asset_pipeline.html
Or the equivalent in the Java Play! framework:
http://www.playframework.com/documentation/2.0/Assets
http://www.playframework.com/documentation/2.0/AssetsLess
http://www.playframework.com/documentation/2.0/AssetsGoogleClosureCompiler
These kinds of frameworks are our "competition" so to speak since we are trying to build similar levels of functionality into KRAD.
I suppose what you guys are talking about below though are "theme"-related assets. It seems like for that as well a custom theme should have a standard directory structure to it which might also include a set of asset directories where you would place css, javascript, etc. Then when the theme gets bundled up you could do the minification (still using maven) but you wouldn't have to manually list out every file (it would just include everything in the appropriate directory based on convention). But I could be oversimplifying things a bit as I haven't really looked much at the custom theme stuff 
At any rate, I would love to see KRAD having a similar level of capability as the Rails asset pipeline where it can automatically minify, etag, and fingerprint for you and the developer gets all of that for free without having to configure anything. I wonder if someone has already built something similar in Java that we could use?
Thanks,
Eric
Improvement
Major
KULRICE-7208 Template
KULRICE-8690 Uif-BaseTheme-parentBean defaults to minimized js which are difficult to debug
Well, we might consider executing the minification programatically as well if that would help. I think it actually might make sense if what we did was provide a standard location where javascript and css files could be added such that they would automatically be loaded and compiled into any views for that particular module (i.e. src/main/assets or src/main/webapp/assets or src/main/webapp/WEB-INF/assets maybe?) . This is how a lot of other convention-based frameworks work and is something which saves time for developers because they really don't have to do anything manually to enable all of this behavior.
See the asset pipeline for Ruby on Rails:
http://guides.rubyonrails.org/asset_pipeline.html
Or the equivalent in the Java Play! framework:
http://www.playframework.com/documentation/2.0/Assets
http://www.playframework.com/documentation/2.0/AssetsLess
http://www.playframework.com/documentation/2.0/AssetsGoogleClosureCompiler
These kinds of frameworks are our "competition" so to speak since we are trying to build similar levels of functionality into KRAD.
I suppose what you guys are talking about below though are "theme"-related assets. It seems like for that as well a custom theme should have a standard directory structure to it which might also include a set of asset directories where you would place css, javascript, etc. Then when the theme gets bundled up you could do the minification (still using maven) but you wouldn't have to manually list out every file (it would just include everything in the appropriate directory based on convention). But I could be oversimplifying things a bit as I haven't really looked much at the custom theme stuff
At any rate, I would love to see KRAD having a similar level of capability as the Rails asset pipeline where it can automatically minify, etag, and fingerprint for you and the developer gets all of that for free without having to configure anything. I wonder if someone has already built something similar in Java that we could use?
Thanks,
Eric