The first pass at implementing Grunt based build scripts has been implement and committed to the project repo. (See:
Error rendering macro 'jira' : Unable to locate JIRA server for this macro. It may be due to Application Link configuration.
- removal of ant based build scripts
- removal of CSS generation (currently a static set of pre-generated files is committed into the repo)
- dependency management of local modules
- custom builds
The builder site has been taken down, with no current plans of replacing it. For now, all builds should be done through the grunt build scripts.
- Head rewriting to switch between using MyInfusion and individual files
- Our current builder tool is hard to update and maintain, doesn't support exclusions, and is feeling a little out of date
- Working with multiple repositories is manual and tedious
- managing relative include paths is error-prone
- managing absolute paths is even worse
- Version handling
- developers want to be able to say "I want exactly this <version>/<revision>/<repository> of Infusion"
- currently not possible to use multiple version of infusion from the same pre-release (e.g. 1.5-SNAPSHOT), but a user might like 1.5-REV_HASH
- Having to build CSS (for UIO) is awkward and easy to forget
- a CSS pre-processor ( less, sass) may be the correct way to implement this.
- Maven and Ant are hard to setup.
- No top-level "infusion" directory when you unpack the built zip
Collaborative Development Project Roadmap
- KILL MAVEN
- Port existing Ant scripts to Grunt
- Update the PHP Builder to use these Grunt scripts instead of Ant (ASK Cindy for help)
- Bower ( what does this offer over just npm? )
- Require.js ( will need some form of require, but may not be Require.js )
JIRAs for require-type functionality:
- FLUID-4911 - "Remove requireStub in favour of the default pattern" - contains BIG COMMENT
- FLUID-4675 - "Stub out require() and fluid.require()"
- Allow the efficient use of "require-style" code in production - the two non-build-time approaches to this are unacceptable in performance -
- The use of "synchronous AJAX" is conceivable only for use in test cases
- The use of "asynchrouons AJAX" is still unsupportable for production code, given its great inferiority in performance to code written literally into head in <script> blocks - this is the only good option for fast IPL code
- Facilitate "multi-repository" work styles together with a checkout of Infusion
- Right now, the biggest barrier to "unbundling" components from our image, or spawning new repositories based on infusion, is the annoyance of ensuring a "stable relative checkout path" between the different repos. We should have a "one-stop shop" that rebases a checkout relative to a checkout of infusion, but also somehow "by magic" not corrupting tags written into the documents when the user tries to checkin again.
- IDEA SCHEME: perhaps a "magic eraser" mode for the build tool, that is run immediately before any "git commit" in order to wipe out evidence of concrete relative include paths in an Infusion-dependent project - then IMMEDIATELY AFTER git commit, the build tool is run again to unpack the relative paths again
- Replacement for our pre-flood PHP-based Infusion builder tool on the WEB
Feature Parity with ant scripts
- Minify js files
- Concatenate js files
- Create zip bundles
- Generate UIO Themes
- Rewrite URL's in demos/unit tests for relase testing
- change URL's to point at the concatenated js file
- Dependency Management
- Include modules
- Exclude modules
- pull in dependencies (e.g. jQuery)
- build css (e.g. UIO themes)
- build font icon sets (see: https://github.com/twolfson/grunt-fontsmith)
ARCHITECTURAL SKETCH for "multi-resolution head rewriting"
Should be possible to write a comment, say, that directs "Include Infusion" - and this is expanded to various levels of detail - this can "pack and unpack" based on the development style (when debugging, running a "demo", or "full production").