[Erlang危機](2.1)項目結構

標籤：erlang

??

原創文章，轉載請註明出處：伺服器非業餘研究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 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裡面增加一些配置項來配置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 3 .
Within these directories, you can do your regular development of an OTP application.

?Applications會遞迴地從git(或hg,或svn)中直接拿到原始碼.他們可以被編譯，並使用特定的選項{erl_opts,List}來編譯. 這個選項也在config檔案中定義3 。
你可以在這些檔案夾中，為自己的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 4. 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 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]。

[Erlang危機](2.1)項目結構