Can you do a git pull and give it another shot?

I believe what is happening is that when maven launches the jython tests,
it doesn't seem to include the jython shim in the class path. For some
reason, this isn't an issue of the .class files that jython generates are
hanging around in the source tree from a previous build, or if the
JYTHONPATH environment variable is set to include the appropriate path.

I'm not sure how long this has been the case, but I suspect it may actually
predate the reactor changes. I think they just triggered the latent issue
for you by adding another file that did not already have a generated .class
file sitting around in the tree.

I've modified JythonTest to add the shim to the classpath and it now works
for me without needing any help from a prior cmake build.

--Rafael



On Mon, Jul 6, 2015 at 8:25 AM, Robbie Gemmell <robbie.gemm...@gmail.com>
wrote:

> Were you running it after having previously used the cmake build in
> the same terminal?
>
> I do indeed have the definition in ctypes, with the cproton file
> importing everything from ctypes. The maven build failed when I ran it
> directly in my git-clean'ed checkout. It then passed when run
> indirectly via cmake and make test. It then passed if run directly
> again. However as it turns out, it also passed in the same terminal
> after I git-clean'ed the checkout again. It failed if I run it again
> directly in the same checkout but using a new terminal where I hadn't
> used the cmake build.
>
> Robbie
>
> On 6 July 2015 at 11:57, Rafael Schloming <r...@alum.mit.edu> wrote:
> > I just ran a maven-only clean build locally with no problems.
> >
> > You should have PN_MILLIS_MAX defined in
> > proton-j/src/main/resources/ctypes.py, and this should be imported from
> > proton-j/src/main/resources/cproton.py. Can you verify that this is as
> > expected?
> >
> > --Rafael
> >
> > On Mon, Jul 6, 2015 at 5:50 AM, Robbie Gemmell <robbie.gemm...@gmail.com
> >
> > wrote:
> >
> >> The recent changes on Proton-J seemed to have created some issues:
> >>
> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j/1032/console
> >>
> >> The module currently requries Java 7 to compile, which is a slightly
> >> out of sync with the compiler source+target still being set to Java 6
> >> (which the above job is using).
> >>
> >> Once using Java 8 to do the maven build locally, the python tests then
> >> failed with:
> >>
> >> proton_tests.utils.SyncRequestResponseTest.test_request_response
> ........
> >> fail
> >> Error during test:  Traceback (most recent call last):
> >>     File "/home/gemmellr/workspace/proton/tests/python/proton-test",
> >> line 360, in run
> >>       phase()
> >>     File
> >> "/home/gemmellr/workspace/proton/tests/python/proton_tests/utils.py",
> >> line 89, in test_request_response
> >>       connection = BlockingConnection(server.url, timeout=self.timeout)
> >>     File
> >>
> "/home/gemmellr/workspace/proton/tests/../proton-c/bindings/python/proton/utils.py",
> >> line 195, in __init__
> >>       self.wait(lambda: not (self.conn.state & Endpoint.REMOTE_UNINIT),
> >>     File
> >>
> "/home/gemmellr/workspace/proton/tests/../proton-c/bindings/python/proton/utils.py",
> >> line 229, in wait
> >>       container_timeout = self.container.timeout
> >>     File
> >>
> "/home/gemmellr/workspace/proton/tests/../proton-c/bindings/python/proton/reactor.py",
> >> line 104, in _get_timeout
> >>       return millis2timeout(pn_reactor_get_timeout(self._impl))
> >>     File
> >>
> "/home/gemmellr/workspace/proton/tests/../proton-c/bindings/python/proton/__init__.py",
> >> line 2337, in millis2timeout
> >>       if millis == PN_MILLIS_MAX: return None
> >>   NameError: global name 'PN_MILLIS_MAX' is not defined
> >>
> >> I notice that the TravisCI job did pass:
> >> https://travis-ci.org/apache/qpid-proton/builds/69665060
> >>
> >> I guess the main difference is it ran via cmake so the proton-c build
> >> was performed before the proton-j tests were run.
> >>
> >> Robbie
> >>
>

Reply via email to