awkward project dir structure and proper release handling

Martynas Pumputis martynasp at gmail.com
Tue Feb 14 08:54:46 EST 2012


Hi,

But whats about running each app[1..3] separately? The problem is that we
want to have two things at once: releases and possibility to e.g. test each
application. If "deps_dir" isn't specified in app1/rebar.config, we won't
be able
do something like "cd app1 && ./rebar eunit".

Martynas

2012/2/13 David Smith <dizzyd at basho.com>

> Hi Motiejus,
>
> 2012/2/11 Motiejus Jakštys <desired.mta at gmail.com>
>
>
>> Now we have this retarded file structure:
>>
>
> I'm not sure I follow -- what's the concern with this structure? The
> configuration in rebar.config?
>
>
>> /app1/rebar.config
>> /app2/rebar.config
>> /app3/rebar.config
>> /deps/proper/rebar.config
>> /deps/couchbeam/rebar.config
>>
>> app1/rebar.config:
>>
>> {lib_dirs, ["../"]}.
>> {deps_dir, ["../deps"]}.
>> {deps, [
>>    app2, app3,
>>    {lager, ".*", {git, "git://github.com/basho/lager.git"}},
>>    {couchbeam, ".*", {git, "https://github.com/benoitc/couchbeam.git",
>>        {branch, "master"}}}
>> ]}.
>>
>
> For app1, you do not need to specify deps_dir or the individual deps if
> you have a top-level rebar.config that has all the deps you need.
>
>
>> Our goals:
>> 1) we want to make a release and run it on nodes specifying the
>> release configs
>>
>
> This should be doable with your setup -- although I would structure it as:
>
> rebar.config <- deps specified here
> apps/app[123]
> deps/
> rel/reltool.config
>
> Does that help?
>
> D.
>
> _______________________________________________
> rebar mailing list
> rebar at lists.basho.com
> http://lists.basho.com/mailman/listinfo/rebar_lists.basho.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/rebar_lists.basho.com/attachments/20120214/febec0cc/attachment.html>


More information about the rebar mailing list