-
Notifications
You must be signed in to change notification settings - Fork 2
Build Process Overview
Table of Contents:
- Goals
- The
web.xml
file - The
webprojects
folder - Build-Time Templating
- SASS Compilation
- JS Compression
- Run-Time Template Compilation
- Merging & Pushing
For more exact details of how the builder works, please read the README.md
.
The goals of the builder are as follows:
- Build the
web.xml
file for the server - Run some basic templating over all files in the
webprojects
folder. - Compile
.scss
files into.css
files - Compress
js
files, unless the--debug
flag is specified - Compile run-time templates
- Merge
js
andcss
files to reduce the number of requests to the server - Push files for all websites to the server
- Push files for the webapp to any smartphone apps
Java web applications use a web.xml
file to organize things like what URLs correspond to what pages. Google does a thorough job of explaining them here. Our builder generates a web.xml
file based off of the patterns described in our servlet-list.csv
file.
The webprojects
folder contains all the web-related code (e.g. .js
and .html
files). It is also what undergoes the most work during compilation.
Some subfolders of the webprojects
folder have special meanings. Generally, any folder beginning with an _
has some sort of special meaning. These special folders come in two varieties: type folders and platform folders.
Type folders specify what type of content they contain:
-
_img
These folders contain images -
_js
These folders contain JavaScript files. Files in this folder which are not.js
files will not be pushed to the output code -
_style
These folders contain.css
,.scss
, and.sass
files. Any files with some other extension will not be push to the output code -
_templates
These folders contain.tmplt
andtspec
files. Any files with some other extension will not be push to the output code -
_raw
These folders contain content which should be pushed to the output code without any sort of modification. -
_ignore
These folders contain content which should not be pushed to the output code -
_skip
The same as_ignore
-
_css
This is a temporary folder used to hold the contents of the_style
folder after SASS compilation is complete
Platform folders contain files that should only be pushed to the output code on certain platforms:
-
_debug
Contents only used if the debug flag is set -
_web
Contents only used when pushing to server -
_iOS
Contents only used when pushing to iOS app
Additionally, there is one special file:
-
_order
When merging JavaScript or CSS, this file (if present) specifies what order those files should be merged in. If the file does not contain a complete list of all files in the folder, the remaining files will be merged in after the files specified by the file.
All folders which are direct children of the webprojects
folder but do not begin with an _
are assumed to represent distinct projects
How our macros actually work is explained elsewhere. Here, we describe where they are defined and which files they are run on.
Currently, macros are defined in the macros
file, though they might be allowed to be defined in more places in the future. Those macros are then run in all the files in the webprojects
folder, unless those files are inside a _raw
or _img
folder.
SASS is a tool for simplifying writing CSS. All the .scss
or .sass
files in a _style
folder undergo SASS compilation
SASS library files should be placed in an _ignore
folder so that they will not be pushed to production. The main SASS library file is at webprojects/_ignore/main.scss
We use uglifyjs
to compress our javascript. However, we only do this compression if we are not in debug mode.
We frequently use lines like:
if({{DEBUG}}) {
...debug code...
}
UglifyJS will automatically remove those lines if {{DEBUG}}
is false
. However, it will spit out a warning message. For this reason, we ignore all warning messages about "side-effect-free statements" or a condition always being true/false.
Incidentally, this method of writing debug-only code is drastically preferred over
IF_DEBUG
...debug code...
END_IF
because it fits better into the flow of JavaScript
How our run-time templates actually work is explained elsewhere. Here, we describe where they are defined/compiled.
The builder lookes for template files within the server/templates
folder and any _templates
folder within the webprojects
directory. Within such folders, any .tmplt
file will be expected to have a corresponding .tspec
file, and vise versa. The templates within the server/templates
folder are compiled into java and made accessible to the server. The templates in a _templates
folder within the webprojects
directory are compiled into both java and javascript, and made accessible both to the server and to the javascript files in the same project.
Suppose we have a type folder with the name _type
at the path webprojects/f1/f2/.../fn/_type
, and the code is currently being outputted to a folder at the path root
. Then one of the following happens:
-
Case 1:
type
isjs
orcss
The contents ofwebprojects/f1/f2/.../fn/_type
(and all subfolders) are merged and placed into the fileroot/f1/f2/.../fn.type
-
Case 2:
type
isstyle
,skip
, orignore
These files are not copied to the output code -
Case 3:
type
israw
The contents ofwebprojects/f1/f2/.../fn/_type
are copied toroot/f1/f2/.../fn/
-
Case 4: Else
The contents ofwebprojects/f1/f2/.../fn/_type
are copied toroot/f1/f2/.../fn/type/
Projects listed in app-web-projects.csv
are pushed to the www
folder of all native apps, as well as the war
folder of the server. All other projects get pushed to the war
folder only.