[erlang-questions] Erlang and Maven

[Olivier Sambourg]

2006/9/9, Arnaud Bailly <abailly@REDACTED>:
>
> "Olivier Sambourg" <olivier.sambourg@REDACTED> writes:
>
> > Hi everyone,
> >
> > Most importantly, you can extend it with plugins (written in Java), so
> I've
> > been toying with the idea of an Erlang plugin, for well... Erlang
> > projects.
>
> That idea is indeed excellent ! I am a  dedicated maven user and a novice
> erlang writer, so I would be more than happy to have such a tool. I
> have written couple of plugins and artifacts, and even a tutorial on
> maven. Development of plugins is quite easy if you dont have to delve
> too deeply in maven's API which is severely underdocumented.


I believe (and hope) such delving will not be necessary (maven's
documentation does not necessarily lack, but is seldom easy to find)

>
> > Things that such a plugin could provide :
> > - "archetype" project creation (creates a typical OTP-like erlang
> project
> > directory structure and basic files - a way to enforce good pratices in
> this
> > area ?)
>
> Easy to do once a common setup is agreed upon. AFAIK, OTP proposes
> such a framework with its applications ?


If we take a look at various OTP applications, the common directory
structure seems to be :

application/
|-> src/ (source files, flat)
|-> include/ (include files...)
|-> doc/ (documentation)
|-> ebin/ (beam files)

I don't know wheter to keep this structure intact (just adding a
pom.xmlfile in the base directory, and directories for test files and
website
generation), or to have a more "mavenish" setup, such as :

application/
|-> pom.xml (maven project descriptor)
|-> src/
  |-> main/
    |-> erlang/ (erlang source files)
    |-> c/ (C code for ports, etc.)
    |-> include/
  |-> test/
    |-> erlang/ (erlang test files)
    |-> c/ (C test files)
  |-> site/
    |-> site.xml (maven site descriptor)
    |-> etc.
|-> target/
  |-> ebin/
  |-> test-ebin/

This last structure ***could*** be useful in a multi-language project, and
has various other advantages from a maven point of view. And of course the
application can be deployed using the standard OTP structure.
Bottom line : I don't know what to choose :)

> - dependencies management (automatic update from a repository, transitive
> > dependencies, etc.)
>
> Tricky as you need a central repository to work with for common
> artifacts. Easy for custom ones of course.


I agree, though integration with REPOS should be possible and greatly ease
things up.

> - run the entire test suite (using EUnit)
> > - generate various reports and the project web site (edoc, eunit
> results,
> > changelogs, etc.)
>
> THat's the real added value of maven
>
> > - project compilation
> > - project deployment (beam files are packaged and deployed with scp, ftp
> or
> > DAV)
>
> Standard.
>
> > - dynamic code loading (typical Erlang feature of course. You could load
> the
> > compiled code on one or more nodes, on your integration or production
> > environment, etc.)
>
> Maybe a plugin to ( http://cargo.codehaus.org) Cargo ?


I was thinking more in the lines of an already running integration or
production node, but Cargo seems to be a good idea, though.
Of course, dynamic code loading would only work with applications which
respect the OTP design guidelines (using supervisors and workers).

> - etc ?
> >
> > I wonder if there are other Maven users among us. Anyway feedback
> > and ideas
>
> Here they are :-)
>
> > would be greatly appreciated (maybe something like this already
> > exists, or
>
> I have been told that some plugins exist for ruby and native
> code. have a look at codehaus.


Codehaus is indeed a good place to look at exemples :) Thanks.


BTW, an added benefit I can see to this idea is the possibility that
> it could foster wider adoption of erlang in Java/j2ee environments and
> more generally in enterprise management systems. I am not a master of
> erlang but I am already amazed by the ease with which some tasks are
> done in erlang when compared to java or other similar settings. Of
> course, concurrency and distribution are known strengths of erlang but
> even data handling seem easier.
>
> May be something could be started ? I am ready for discussion a to
> throw some time in.
>
> regards,
> --
> OQube < software engineering \ génie logiciel >
> Arnaud Bailly, Dr.
> \web> http://www.oqube.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20060910/bfa5e08d/attachment.htm>