missing app file
watson.timothy at gmail.com
Fri Oct 28 19:00:30 EDT 2011
And here it is. Very experimental, but demonstrates what I'm talking about:
On 28 October 2011 20:16, Tim Watson <watson.timothy at gmail.com> wrote:
> On 28 October 2011 18:38, Joel Reymont <joelr1 at gmail.com> wrote:
>> On Oct 28, 2011, at 5:51 PM, Steven Gravell wrote:
>> > If you're writing a release then put release specific apps in an apps
>> > If you're writing an app used by other apps or releases then put it in
>> the root directory of the project.
>> What about a patch that makes rebar look inside when it finds apps/?
>> Would this be accepted into the basho repo?
> Obviously dizzy and his fellow maintainers are the only ones who can answer
> that, but personally I'm not sure if it's more than just a sticking plaster.
> The fundamental thing is that not every project is going to be packaged in
> what rebar considers "the right way" and you're never going to get around
> that. Even zotonic suffers from this and I suspect other major projects like
> rabbitmq, many which are still using make.
> Personally I think that you've got to accept some rebar based projects want
> to use dependencies that aren't packaged up nicely and they will always
> require *special* treatment. That's why I've been working on a plugin to
> install required *things* without enforcing that they're OTP applications (
> https://github.com/hyperthunk/rebar_alt_deps), another plugin to be able
> to execute foreign build tools like make/maven/rake/etc as part of your
> build process (https://github.com/hyperthunk/rebar_alien_plugin) and yet
> another plugin to tweak the code path during rebar execution, so that you
> can have things that aren't really deps or sub_dirs, but still get picked up
> by reltool and other important parts of the build (
> https://github.com/hyperthunk/rebar_paths_plugin). I believe that it's
> possible to include completely incompatible dependencies (like ejabberd) in
> this way and just avoid trying to force them to be rebar compatible.
> Naturally using some wacky custom plugins is also a non-standard approach,
> but at least they're very small code bases and easy to customise if you need
> to, versus having to maintain some custom fork of a complex project like
> ejabberd and it's build process.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rebar