原创文章，转载请注明出处：服务器非业余研究http://blog.csdn.net/erlib 作者Sunface

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.

?OTP applications和OTP release项目结构是不同的，一个OTP application 可以看成一个拥有最高级监控树(如果有的话)，并且下面可能有一大堆的依赖项(a bunch of dependencies).一个OTP release通常是多个OTP applications的组合，这些application之间可能会有依赖关系，也可能没有。这就形成了两种主要的部署applicaitons的方式。

OTP Applications

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

?对于OTP applicaitons，合适的结构基本同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 is the deps/ directory, which is fairly useful to have, but that will be generated automatically by rebar ² 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.

?新加的文件夹:deps/ 非常有用的一个文件夹。这个文件夹如果有必要也可以直接通过rebar自动生成²。
这是因为在Erlang没有标准的包管理器(canonical package management)。现在的做法是用rebar来做为每一个项目在本地获取依赖项的工作。

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:

?这可以解决一大堆的冲突，但也意味着生个项目都要下载自己的依赖项目啦。
?下面是通过在rebar.config里面增加一些配置项来配置rebar：
----------------------------------------------------------------------------------
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 ³ .
Within these directories, you can do your regular development of an OTP application.

?Applications会递归地从git(或hg,或svn)中直接拿到源代码.他们可以被编译，并使用特定的选项{erl_opts,List}来编译. 这个选项也在config文件中定义³ 。
你可以在这些文件夹中，为自己的OTP application开发功能。

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.

?为了编译他们，你可以使用rebar get-deps把依赖项也下载下来编译，并马上构建依赖项和你自己的app。
?当你把自己的application开源出来时，要把它的依赖项给去掉。因为其他开发者的application很有可能和你一样依赖同样的application，没有必要重复装载他们多次。

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

?构建系统(在这里，指rebar）应当能判断出重复的依赖项并这些重复的项只会被加载一次。

[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.

[注2]：很多人都是把rebar集成在自己的applicaiton中。这最初是为了帮助那些从来不使用rebar的人快速掌握这个工具，你可以在系统里全局自由安装rebar，也可以在局部保存一个特定的版本来构建你的系统。
[注3]：你可以输入rebar help来查看更多的帮助信息。

OTP Releases

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

?对于Releases,结构会有一点小小的变化。Releases是applicaitons的集合，他们的结构也应当反映出这些。

Instead of having a top-level app, applications should 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应当使用嵌套的形式并分成apps和deps两种类型，而不是那些自上而下的app结构, apps文件夹里面包括你自己applicaitons的源文件(内部业务代码)，deps文件夹包括独立管理依赖application。
---------------------------------------------------------------------------------
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 Systool and Reltool have been covered before ⁵, and can allow the user plenty of power. An easier tool that recently appeared is relx ⁶.
A relx configuration file for the directory structure above would look like:

?这种结构有助于自动生成releases。Systool,Reltool等工具以前都会支持，用起来非常给力。相对容易上手的还有最近推出的一个简单点的工作：relx⁶。
?relx的配置文件格式如下：
----------------------------------------------------------------------------------
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.

?你可以调用./relx(在当前文件夹下调用)来创建一个release,就能在 _rel/文件夹来找到这个release.

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:

?如果你更喜欢使用rebar来创建，你可能通过使用在rebar.config里面的rebar hook 来把创建release作为项目编译的一部分。
----------------------------------------------------------------------------------
1 {post_hooks,[{compile, "./relx"}]}.
----------------------------------------------------------------------------------

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

每次运行rebar compile时，都会新建一个release.

[4] I say should because many Erlang 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

[注4]：我说应当(should),是因为大量的Erlang开发者都会把最终的系统放在src做成单一的应用(a single top-level application),而不是在deps使用依赖项，这并不能完美地解决由于OTP文件结构引起的冲突.开发者之所以这样做，是因为他们想从源代码构建产品并使用自定义的命令来驱动(boot)他们的application.
[注5]: http://learnyousomeerlang.com/release-is-the-word
[注6]：https://github.com/erlware/relx/wiki]。

[Erlang危机](2.1)项目结构