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

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

项目结构

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可以认为是拥有一个最高级的监控树(如果有的话)，并且下面可能有一系列依赖项.一个OTP release通常是多个OTP application的组合，这些applications之间可能会有依赖关系，也可能没有。这就形成了两种主要的applicaiton部署的方式。

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

 这里面有个新面孔：deps, 这是一个非常有用的文件夹，可以直接通过rebar自动生成2。因为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来完成。
 ----------------------------------------------------------------------------------
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.
   在系统中安装好rebar后，可以从git(或hg,或svn)中直接拿到Applications的源代码。代码可以使用特定的选项{erl_opts,List}来编译（这个选项也在config文件中定义）3  。你也可以使用这些Applications,为自己的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，没有必要重复加载依赖项。 

  

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 4. Releases are collections of applications, and their structures should reflect that.

 对于Releases,结构会有点不同。Releases是applicaiton的集合，通过这些application的结构也能体现出来。

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两个目录： apps包含applicaitons的源文件(内部商业代码)，deps独立管理依赖项。

 ---------------------------------------------------------------------------------
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 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 would look like:

 这种结构有助于自动生成releases，并且Systool,Reltool等工具以前就会支持，用起来非常给力。相对容易上手的还有最近推出的一个工具：relx6。
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]。