That seemed to do the trick. Running the maven build in a clean checkout in clean terminal now works, so long as you use a version of Java able to build the recent source; the compilation issue is still there otherwise: https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-c/ https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j/
Robbie On 6 July 2015 at 13:55, Rafael Schloming <r...@alum.mit.edu> wrote: > 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 >> >> >>
