rename examples to relx from relcool

1 files changed, 0 insertions, 81 deletions

diff --git a/examples/relcool.config b/examples/relcool.config
deleted file mode 100644
index 77d7acf..0000000
--- a/examples/relcool.config
+++ /dev/null
@@ -1,81 +0,0 @@
-%% -*- mode: Erlang; fill-column: 80; comment-column: 75; -*-
-%% Example Relcool Config
-%% ======================
-%%
-%% This is an example relcool config whose purpose is to demonstrate all of the
-%% options available in relcool. Its not expected that you will use all of the
-%% things here. In fact, there is a high likely hood that *your* relcool.config
-%% will be extremely minimal, as relcool does a very good job of figuring out
-%% things on its own.
-%%
-%% The Release We Are Building
-%% ---------------------------
-%%
-%% Lets say we have a release called sexpr. The sexpr release supports versions
-%% 0.0.1 and 0.0.2 with different dependencies. 0.0.1 requires erlware commons
-%% 0.8.0 or lesser. 0.0.2 requires erlware_commons 0.8.1 or greater along with
-%% neotoma (any version). We also do not want neotoma to be loaded. We also want
-%% our default release. the one we build in the common case to be sexper 0.0.2.
-
-%% You can tell relcool about additional directories that you want searched for
-%% otp apps during the discovery process. You do that in the 'paths' config. You
-%% can also specify these paths on the command line with `-p`. Be aware that
-%% relcool plays well with rebar so if you have a deps directory in the current
-%% directory it will be automatically added.
-{paths, ["/opt/erlang_apps"]}.
-
-%% If needed you can use a specific vm.args file instead of the
-%% one automatically generated by relx.
-{vm_args, "./config/vm.args"}.
-
-%% If you have a sys.config file you need to tell relcool where it is. If you do
-%% that relcool will include the sys.config in the appropriate place
-%% automatically.
-{sys_config, "./config/sys.config"}.
-
-%% relcool will include erts by default. However, if you don't want to include
-%% erts you can add the `include_erts` tuple to the config and tell relcool not
-%% to include it.
-{include_erts, false}.
-
-%% The default start script relcool creates is basic. For a more complete start
-%% script add the extended_start_script option.
-{extended_start_script, true}.
-
-%% When we have multiple releases relcool needs to know which one to build. You
-%% can specify that on the command line with the `-n` and `-v` arguments to
-%% relcool. However, it is often more convenient to do it in the config.
-{default_release, sexpr, "0.0.2"}.
-
-{release, {sexpr, "0.0.1"},
- [sexpr,
-  %% There are two syntaxes for constraints.
-  %% The first is the tuple syntax shown here.
-  {erlware_commons, "0.8.0", '<='}]}.
-
-{release, {sexpr, "0.0.2"},
- [sexpr,
-
-  %% This is the second constraint syntax, it is interchangeable with the tuple
-  %% syntax and its up to you which you find more readable/usable.
-  "erlware_commons>=0.8.1",
-
-  %% You can put the release load types in the release spec here in exactly the
-  %% same way that you can do it for a normal relfile. The syntax is
-  %% {<constraint>, <type>}.
-  {neotoma, load}]}.
-
-%% During development its often the case that you want to substitute the app
-%% that you are working on for a 'production' version of an app. You can
-%% explicitly tell relcool to override all versions of an app that you specify
-%% with an app in an arbitrary directory. Relcool will then symlink that app
-%% into the release in place of the specified app. be aware though that relcool
-%% will check your app for consistancy so it should be a normal OTP app and
-%% already be built.
-{overrides, [{sexpr, "../sexpr"}]}.
-
-
-%% In some cases you might want to add additional functionality to relcool. You
-%% can do this via a 'provider'. A provider is an implementation of the relcool
-%% provider behaviour. This probably shouldn't be needed very often.
-{add_providers, [my_custom_functionality]}.