Ebuild for stomp ruby 1.1.6 package. This will be dep for mcollective [1] which I plan to add to portage once this package has been added by the Ruby herd. Thanks! [1] https://github.com/ramereth/ramereth-overlay/tree/master/app-admin/mcollective
Created attachment 259648 [details] stomp-1.1.6.ebuild
It fails tests like so (+ many more). I guess this needs a sandboxed live stomp server? 1) Error: test_ack_api_works(TestClient): Errno::ECONNREFUSED: Connection refused - connect(2) ./test/../lib/stomp/connection.rb:426:in `initialize' ./test/../lib/stomp/connection.rb:426:in `open' ./test/../lib/stomp/connection.rb:426:in `open_tcp_socket' ./test/../lib/stomp/connection.rb:471:in `open_socket' ./test/../lib/stomp/connection.rb:110:in `socket' ./test/../lib/stomp/connection.rb:103:in `synchronize' ./test/../lib/stomp/connection.rb:103:in `socket' ./test/../lib/stomp/connection.rb:83:in `initialize' ./test/../lib/stomp/client.rb:93:in `new' ./test/../lib/stomp/client.rb:93:in `initialize' ./test/test_client.rb:9:in `new' ./test/test_client.rb:9:in `setup'
Also, the package contains specs and tests, but you only try to run the tests. Is there a specific reason for that? The ebuild also needs a DOCDIR setting, currently the documentation is built but not installed.
(In reply to comment #2) > It fails tests like so (+ many more). I guess this needs a sandboxed live stomp > server? Yes I believe it does. How should I work around that?
(In reply to comment #4) > Yes I believe it does. How should I work around that? In order of preference: 1. set up a controlled instance of a stomp server and run tests against that 2. detect if a stomp server is available and fail gracefully on those tests requiring them 3. don't run these tests at all I don't know anything about stomp so I can't tell beforehand which one if most feasible.
(In reply to comment #5) > (In reply to comment #4) > > > Yes I believe it does. How should I work around that? > > In order of preference: > > 1. set up a controlled instance of a stomp server and run tests against that > 2. detect if a stomp server is available and fail gracefully on those tests > requiring them > 3. don't run these tests at all > > I don't know anything about stomp so I can't tell beforehand which one if most > feasible. > I don't think it'll be feasible to have it figure out if there's a stomp server running and where its at. I'd prefer to just go with #3. Want me to add the logic so that works? Thanks-
I have now added stomp 1.1.7 to CVS. It turns out that there are specs that test the code internally and tests that test the connection with the stomp server, so we can at least test the internal stuff with specs. Due to this I dropped jruby support since its specs don't pass.
