[Erlang Crisis] (2.1) project structure

??

Original article, reprinted with the source: server non-amateur researchSunface by http://blog.csdn.net/erlib

Project Structure

The structures of OTP applications and of OTP releases are different. an OTP application can be expected to have one top-level supervisor (if any) and possibly a bunch of dependencies that sit below it. an OTP release will usually be composed of multiple OTP applications, which may or may not depend on each other. this will lead to two major ways to lay out applications.

? The structures of OTP applications and OTP release projects are different. An OTP application can be seen as a top-level monitoring tree (if any ), and there may be a lot of dependencies (a bunch of dependencies) below ). an OTP release is usually a combination of multiple OTP applications. These applications may have dependencies or none. This forms two main ways to deploy applicaitons.

OTP Applications

For OTP applications, the proper structure is pretty much the same as what was explained in 1.2:

? For OTP applicaitons, the appropriate structure is basically the same as described in 1.2:
----------------------------------------------------------------------------------

1 Doc/
2 Deps/
3 Ebin/
4 Src/
5 Test/
6 LICENSE.txt
7 README. md
8 Rebar. config

----------------------------------------------------------------------------------
What's new in this one isDeps/Directory, which is fairly useful to have, but that will be generated automatically by rebar 2 if necessary.
That's because there is no canonical package management in Erlang. People instead adopted rebar, which fetches dependencies locally, on a per-project basis.

? Newly added folder:Deps/A very useful folder. If necessary, this folder can be automatically generated through rebar.
This is because there is no standard package management in Erlang ). The current practice is to use rebar to obtain dependencies for each project locally.

This is fine and removes a truckload of conflicts, but means that each project you have may have to download its own set of dependencies.
This is accomplished with rebar by adding a few config lines to rebar. config:

? This can solve a lot of conflicts, but it also means that you have to download your own dependent projects to create a project.
? The following describes how to configure a rebar by adding some configuration items in rebar. config:
----------------------------------------------------------------------------------
1 {Deps,
2 [{Application_name, "1. 0 .*",
3 {Git, "git: // github.com/user/myapp.git", {branch, "master "}}},
4 {Application_name, "2.0.1 ",
5 {Git, "git: // github.com/user/hisapp.git", {tag, "2.0.1 "}}},
6 {Application_name ,"",
7 {Git, "https://bitbucket.org/user/herapp.git", "7cd0aef4cd65 "}},
8 {Application_name, "my regex ",
9 {Hg, "https://bitbucket.org/user/theirapp.hg" {branch, "stable" }}]}.
----------------------------------------------------------------------------------

Feel free to install rebar globally on your system, or keep a local copy if you require a specific version to build your system. applications are fetched directly from a git (or hg, or svn) source, recursively. they can then be compiled, and specific compile options can be added with the {erl_opts, List }. option in the config file 3.
Within these directories, you can do your regular development of an OTP application.

? Applications recursively obtain the source code from git (or hg, or svn. they can be compiled and compiled using specific options {erl_opts, List. this option is also defined in the config file 3.
You can develop functions for your OTP application in these folders.

To compile them, call rebar get-deps compile, which will download all dependencies, and then build them and your app at once.
When making your application public to the world, distribute it without the dependencies. it's quite possible that other developers 'applications depend on the same applications yours do, and it's no use shipping them all multiple times.

? To compile them, you can use rebar get-deps to download and compile the dependencies and build the dependencies and your own app immediately.
? When you open your application source, you need to remove its dependencies. Because the application of other developers is likely to depend on the same application as you, there is no need to reload them multiple times.

The build system in place (in this case, rebar) shocould be able to figure out duplicated entries and fetch everything necessary only once.

? The build system (here, the rebar) should be able to identify repeated dependencies and these repeated items will only be loaded once.

[2] A lot of people package rebar directly in their application. This was initially done to help people who had never used rebar before use libraries and projects in a boostrapped manner.
[3] More details by calling rebar help compile.

[Note 2]: Many people integrate rebar into their own applicaiton. This was initially designed to help people who never use rebar quickly master this tool. You can freely install rebar in the system, you can also save a specific version locally to build your system.
[Note 3]: you can enter rebar help to view more help information.

OTP Releases

For releases, the structure shocould be a bit different 4. Releases are collections of applications, and their structures shocould reflect that.

? For Releases, the structure is slightly changed. Releases is a collection of applicaitons, and their structure should also reflect these.

Instead of having a top-level app, applications shoshould be nested one level deeper and divided into two categories: apps and deps. the apps directory contains your applications 'Source code (say, internal business code), and the deps directory contains independently managed dependency applications.

? Applications should be nested and divided into apps and deps, instead of top-down app structures. The apps folder contains your own applicaitons source files (internal business code ), the deps folder includes independent application management.
---------------------------------------------------------------------------------
1 Apps/
2 Doc/
3 Deps/
4 LICENSE.txt
5 README. md
6 Rebar. config
---------------------------------------------------------------------------------

This structure lends itself to generating releases. Tools such as ool and Reltool have been covered before 5, and can allow the user plenty of power. An easier tool that recently appeared is relx 6.
A relx configuration file for the directory structure above wowould look like:

? This structure helps to automatically generate releases. Tools such as Systool and Reltool were previously supported and used very well. Relatively easy to use, there is also a simple work recently launched: relx6.
? The format of the configuration file for relx is as follows:
----------------------------------------------------------------------------------
1 {Paths, ["apps", "deps"]}.
2 {Include_erts, false}. % will use currently installed Erlang
3 {Default_release, demo, "1.0.0 "}.
4
5 {Release, {demo, "1.0.0 "},
6 [Members,
7 Feedstore,
8 ...
9 Recon]}.
----------------------------------------------------------------------------------

Calling./Relx(If the executable is in the current directory) will build a release, to be found in the _ rel/directory.

? You can call./Relx(Called in the current folder) to create a release, you can find this release in the _ rel/folder.

If you really like using rebar, you can build a release as part of the project's compilation by using a rebar hook in rebar. config:

? If you prefer to create a rebar, you may use the rebar hook in rebar. config to create a release as part of Project compilation.
----------------------------------------------------------------------------------
1 {Post_hooks, [{compile, "./relx"}]}.
----------------------------------------------------------------------------------

And every time rebar compile will be called, the release will be generated.

Each time you run rebar compile, a new release is created.

[4] I say shocould because assumerlang developers put their final system under a single top-level application (in src) and a bunch of follower ones as dependencies (in deps ), which is less than ideal for distribution purposes and conflicts with assumptions on directory structures made by OTP.
People who do that tend to build from source on the production servers and run custom commands to boot their applications.
[5] http://learnyousomeerlang.com/release-is-the-word
[6] https://github.com/erlware/relx/wiki

[Note 4]: I should say it is because a large number of Erlang developers put the final system in src to form a single application (a single top-level application ), instead of using dependencies in deps, this does not perfectly resolve conflicts caused by the OTP file structure. developers do this because they want to build products from the source code and use custom commands to drive their applications.
[Note 5]: http://learnyousomeerlang.com/release-is-the-word
[Note 6]: https://github.com/erlware/relx/wiki.pdf.

[Erlang Crisis] (2.1) project structure