1. Applied Rebar
Common Patterns for Usage

2. Goals
Examine common patterns for organization of
Erlang applications/libraries
Discuss tradeoffs

3. OTP Terminology
Application
1..n modules + resource file (.app)
Release
1..n applications + resource file (.rel)
System (aka “Target System”)
Release + Embedded ERTS

4. How rebar works
Three module chains: app, rel, any
App dir test: ebin/*.app or src/*.app.src
Rel dir test: reltool.config

5. Helper bits
Rebar dependencies
Source-based download/compilation
{deps, [{App, {git, Url, Tag}}]}
Reltool can automagically generate a release +
system from a config file
Rebar wraps reltool and uses convention of reltool.config

6. A bit of philosophy...
Apps should be compiled from source
Ensures correctness for platform/ERTS version
Allows isolation of dependencies
No central repo of applications
Curation not required
Curation not provided, either

7. Simple App
Follows standard conventions
src, ebin, include, priv, c_src
May have deps in rebar.config
Examples:
cowboy, gproc, folsom

8. Escripted App
Single app
May have dependencies
Example: basho_bench

9. Composite App
Multiple apps
apps/app1..n
May have dependencies
reltool.config in subdir
rel/reltool.config

10. Packaged System
No apps in repo; all apps are dependencies
Reltool.config in subdir
Predominant example: Riak

11. The Future
TBD. :)