My environment is as follows:
Apache Maven 3.0.2 (r1056850; 2011-01-08 16:58:10-0800)
Java version: 1.6.0_24, vendor: Apple Inc.
OS name: "mac os x", version: "10.6.7", arch: "x86_64", family: "mac"
Erlang version:R14B02
Thanks for any help you can provide.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2011-04-15
I should mention that I was able to get this working on the older 1.0.0-beta version of the plugin.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
we have not officially fixed the plugin for Maven 3.x yet, so the 2.0.0 plugin-release works best with Maven2, even though it should not matter for backend node initialization and connection.
I am also using a Mac OS X 10.6.7 setup, but I've chosen to stay with Maven 2.2.1 for a little longer, meaning that I've compiled and re-installed the 2.2.1 version after the Apple update
I've done some tests with a couple of simple projects using Maven3 but I can't reproduce your problem.
I think it would help if you could describe your project setup a bit more, perhaps providing your POM for us to take a look.
Other things to try out and consider is how your hostname is resolved. The backend node is started using the "-name" parameter so it tries to use a fully qualified hostname as backend node name.
I hope this helps and please let us know how it goes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
compared to 1.0.0-beta the new version now uses jinterface and distributed erlang instead of
calling
erl -eval
To me this sounds like a typical erlang vm name resolution problem. Did you already try distributed erlang on your machine (e.g. by connecting two shell nodes using net_kernerl:connect/1)? On some machines there's something weird going on when trying to connect to nodes started with short hostnames.
Switching to long names (e,g, @localhost.localdomain) for the default backend nodes could be a topic for a future plugin release.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2011-05-24
Hi all,
I know it's been a while since I posted this issue; I was working on another project and finally got a chance to revisit this. Thanks to both of you for your responses. With schlagert's hint about trying running a distributing erlang I was able to find the problem. The .erlang.cookie in my home directory was owned by root and ultimately was causing a permissions issue. i deleted this file and reran and the plugin ran just fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We also know of other problems with backend node connectivity. At least on some MacOS X hosts jinterface could not connect to the backend nodes. Version 2.1.0 will contain a patch that will force the backend nodes to be started with
erl-namenode@IP
where the IP is read from one of the currently active network interfaces. The loopback device will be considered last. This should solve some of these problems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
Perhaps I'm missing something, but I'm unable to use this plugin due to troubles connecting to the erlang backend. I'm getting the following error:
I'm performing a simple
on a erlang-otp packaged project.
My environment is as follows:
Apache Maven 3.0.2 (r1056850; 2011-01-08 16:58:10-0800)
Java version: 1.6.0_24, vendor: Apple Inc.
OS name: "mac os x", version: "10.6.7", arch: "x86_64", family: "mac"
Erlang version:R14B02
Thanks for any help you can provide.
I should mention that I was able to get this working on the older 1.0.0-beta version of the plugin.
Hi dimnone,
we have not officially fixed the plugin for Maven 3.x yet, so the 2.0.0 plugin-release works best with Maven2, even though it should not matter for backend node initialization and connection.
I am also using a Mac OS X 10.6.7 setup, but I've chosen to stay with Maven 2.2.1 for a little longer, meaning that I've compiled and re-installed the 2.2.1 version after the Apple update
I've done some tests with a couple of simple projects using Maven3 but I can't reproduce your problem.
I think it would help if you could describe your project setup a bit more, perhaps providing your POM for us to take a look.
Other things to try out and consider is how your hostname is resolved. The backend node is started using the "-name" parameter so it tries to use a fully qualified hostname as backend node name.
I hope this helps and please let us know how it goes.
These are the projects I used to test with Maven 3.x btw.
* https://github.com/olle/mochiweb
* https://github.com/olle/mochigo
Hi,
compared to 1.0.0-beta the new version now uses jinterface and distributed erlang instead of
calling
To me this sounds like a typical erlang vm name resolution problem. Did you already try distributed erlang on your machine (e.g. by connecting two shell nodes using net_kernerl:connect/1)? On some machines there's something weird going on when trying to connect to nodes started with short hostnames.
Switching to long names (e,g, @localhost.localdomain) for the default backend nodes could be a topic for a future plugin release.
Hi all,
I know it's been a while since I posted this issue; I was working on another project and finally got a chance to revisit this. Thanks to both of you for your responses. With schlagert's hint about trying running a distributing erlang I was able to find the problem. The .erlang.cookie in my home directory was owned by root and ultimately was causing a permissions issue. i deleted this file and reran and the plugin ran just fine.
Hi dimnone,
glad I could help.
We also know of other problems with backend node connectivity. At least on some MacOS X hosts jinterface could not connect to the backend nodes. Version 2.1.0 will contain a patch that will force the backend nodes to be started with
where the IP is read from one of the currently active network interfaces. The loopback device will be considered last. This should solve some of these problems.