[erlang-questions] Erlang and Maven
Sun Sep 10 16:00:55 CEST 2006
2006/9/9, Arnaud Bailly <>:
> "Olivier Sambourg" <> writes:
> > Hi everyone,
> > Most importantly, you can extend it with plugins (written in Java), so
> > 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
> > directory structure and basic files - a way to enforce good pratices in
> > 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 :
|-> 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
generation), or to have a more "mavenish" setup, such as :
|-> pom.xml (maven project descriptor)
|-> erlang/ (erlang source files)
|-> c/ (C code for ports, etc.)
|-> erlang/ (erlang test files)
|-> c/ (C test files)
|-> site.xml (maven site descriptor)
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
> - run the entire test suite (using EUnit)
> > - generate various reports and the project web site (edoc, eunit
> > changelogs, etc.)
> THat's the real added value of maven
> > - project compilation
> > - project deployment (beam files are packaged and deployed with scp, ftp
> > DAV)
> > - dynamic code loading (typical Erlang feature of course. You could load
> > 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.
> OQube < software engineering \ génie logiciel >
> Arnaud Bailly, Dr.
> \web> http://www.oqube.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions