You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by Robbie Gemmell <ro...@gmail.com> on 2015/07/06 11:50:21 UTC
ProtonJ compilation and test failures
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
Re: ProtonJ compilation and test failures
Posted by Robbie Gemmell <ro...@gmail.com>.
On 6 July 2015 at 16:48, Gordon Sim <gs...@redhat.com> wrote:
> On 07/06/2015 04:08 PM, Rafael Schloming wrote:
>>
>> Any sort of missing class really should be a compile time exception, which
>> I think means you must have stale class files *somewhere*. You could try
>> doing a find checkout -name "*.class" just as a sanity check.
>
>
> I have deleted all the .class files that are generated in the source tree
> (and deleted the entire build directory).
>
> The class files are rebuilt for ProtonJInterop, alongside those for
> InteropTest and JythonTest in
> ./tests/target/test-classes/org/apache/qpid/proton/:
>
> ProtonJInterop$1.class
> ProtonJInterop.class
> ProtonJInterop$Recv.class
> ProtonJInterop$Send.class
> ProtonJInterop$SendHandler.class
>
> However the test run still reports that it cannot load these.
>
Do you have anything interesting in your build dir structure, like
spaces etc, that we might not?
>> Also, it's
>> possible something in your local maven repo is somehow coming into play,
>> maybe blow that away and rebuild it and/or do an mvn install to be sure
>> that remove dependencies aren't out of sync with local code?
>
>
> I removed everything I could find that was proton related from the mvn
> repository, but that didn't help.
>
If you are running maven from the root of the proton tree to build and
test the modules then its building everything proton-related there is
and shouldn't look in its local repo for those as a result. Each
modules classes are loaded using the class files in the target dirs
when testing, again not the local repo. If you build certain modules
in isoluation of its dependencies, then it will look in the local repo
(and/or remote repos, based on update schedules and last check times)
to get any bits that it needs which aren't already part of the current
build, in which case yes you would want to 'mvn install' those bits to
the local repo if you have local changes, or allow them to be updated
from remote repositories if you dont (again, based on schedule..use -U
to force repo update check) or for example if you are using mismatched
local and remote snapshot bits.
Robbie
Re: ProtonJ compilation and test failures
Posted by Robbie Gemmell <ro...@gmail.com>.
On 6 July 2015 at 18:24, aconway <ac...@redhat.com> wrote:
> On Mon, 2015-07-06 at 17:31 +0100, Gordon Sim wrote:
>> On 07/06/2015 05:22 PM, aconway wrote:
>> > On Mon, 2015-07-06 at 16:48 +0100, Gordon Sim wrote:
>> > > On 07/06/2015 04:08 PM, Rafael Schloming wrote:
>> > > > Any sort of missing class really should be a compile time
>> > > > exception, which
>> > > > I think means you must have stale class files *somewhere*. You
>> > > > could try
>> > > > doing a find checkout -name "*.class" just as a sanity check.
>
> Not maven's fault
<gasp>
> (I still hate maven)
Poor maven, just can't find love from aconway ;)
> missing CLASSPATH in cmake
> config. Fixed.
>
> 89fca58 NO-JIRA: Add missing CLASSPATH needed to run python tests in
> proton-c/CMakeLists.txt
>
> We could improve the setup by moving all the config.sh paths into cmake
> variables and using them consistently in cmake and to generate
> config.sh.
>
> Also the fact that tests in proton/test are driven from proton/proton
> -c/CMakeLists.txt is odd. If the tests live at top level (which is OK
> by me) then the test drivers should too. Especially when (as in this
> case) they are pulling code from both proton-c and proton-j.
>
> I'm not doing that right now because it requires thought, maybe later
> if nobody else does it.
Re: ProtonJ compilation and test failures
Posted by aconway <ac...@redhat.com>.
On Mon, 2015-07-06 at 17:31 +0100, Gordon Sim wrote:
> On 07/06/2015 05:22 PM, aconway wrote:
> > On Mon, 2015-07-06 at 16:48 +0100, Gordon Sim wrote:
> > > On 07/06/2015 04:08 PM, Rafael Schloming wrote:
> > > > Any sort of missing class really should be a compile time
> > > > exception, which
> > > > I think means you must have stale class files *somewhere*. You
> > > > could try
> > > > doing a find checkout -name "*.class" just as a sanity check.
Not maven's fault (I still hate maven) missing CLASSPATH in cmake
config. Fixed.
89fca58 NO-JIRA: Add missing CLASSPATH needed to run python tests in
proton-c/CMakeLists.txt
We could improve the setup by moving all the config.sh paths into cmake
variables and using them consistently in cmake and to generate
config.sh.
Also the fact that tests in proton/test are driven from proton/proton
-c/CMakeLists.txt is odd. If the tests live at top level (which is OK
by me) then the test drivers should too. Especially when (as in this
case) they are pulling code from both proton-c and proton-j.
I'm not doing that right now because it requires thought, maybe later
if nobody else does it.
Re: ProtonJ compilation and test failures
Posted by Gordon Sim <gs...@redhat.com>.
On 07/06/2015 05:22 PM, aconway wrote:
> On Mon, 2015-07-06 at 16:48 +0100, Gordon Sim wrote:
>> On 07/06/2015 04:08 PM, Rafael Schloming wrote:
>>> Any sort of missing class really should be a compile time
>>> exception, which
>>> I think means you must have stale class files *somewhere*. You
>>> could try
>>> doing a find checkout -name "*.class" just as a sanity check.
>>
>> I have deleted all the .class files that are generated in the source
>> tree (and deleted the entire build directory).
>>
>> The class files are rebuilt for ProtonJInterop, alongside those for
>> InteropTest and JythonTest in
>> ./tests/target/test-classes/org/apache/qpid/proton/:
>>
>> ProtonJInterop$1.class
>> ProtonJInterop.class
>> ProtonJInterop$Recv.class
>> ProtonJInterop$Send.class
>> ProtonJInterop$SendHandler.class
>>
>> However the test run still reports that it cannot load these.
>>
>>> Also, it's
>>> possible something in your local maven repo is somehow coming into
>>> play,
>>> maybe blow that away and rebuild it and/or do an mvn install to be
>>> sure
>>> that remove dependencies aren't out of sync with local code?
>>
>> I removed everything I could find that was proton related from the
>> mvn
>> repository, but that didn't help.
>>
>
> Have you tried `rm -rf $HOME/.m2`?
I haven't. I was hoping to avoid that as then next time you invoke it,
maven has to download half the interwebs.
> Maven stuffs it with class files
> from who-knows-where which can lurk for months or years before screwing
> up builds in a brand-new checkout. I hate maven. (and cmake, and
> automake. I'm not a bigot but you just can't trust build systems I'm
> telling you!)
I don't like maven either, but if the build is able to get messed up by
it in a way that mvn clean doesn't fix, then to me that suggests the
build is a little broken somehow.
Re: ProtonJ compilation and test failures
Posted by aconway <ac...@redhat.com>.
On Mon, 2015-07-06 at 16:48 +0100, Gordon Sim wrote:
> On 07/06/2015 04:08 PM, Rafael Schloming wrote:
> > Any sort of missing class really should be a compile time
> > exception, which
> > I think means you must have stale class files *somewhere*. You
> > could try
> > doing a find checkout -name "*.class" just as a sanity check.
>
> I have deleted all the .class files that are generated in the source
> tree (and deleted the entire build directory).
>
> The class files are rebuilt for ProtonJInterop, alongside those for
> InteropTest and JythonTest in
> ./tests/target/test-classes/org/apache/qpid/proton/:
>
> ProtonJInterop$1.class
> ProtonJInterop.class
> ProtonJInterop$Recv.class
> ProtonJInterop$Send.class
> ProtonJInterop$SendHandler.class
>
> However the test run still reports that it cannot load these.
>
> > Also, it's
> > possible something in your local maven repo is somehow coming into
> > play,
> > maybe blow that away and rebuild it and/or do an mvn install to be
> > sure
> > that remove dependencies aren't out of sync with local code?
>
> I removed everything I could find that was proton related from the
> mvn
> repository, but that didn't help.
>
Have you tried `rm -rf $HOME/.m2`? Maven stuffs it with class files
from who-knows-where which can lurk for months or years before screwing
up builds in a brand-new checkout. I hate maven. (and cmake, and
automake. I'm not a bigot but you just can't trust build systems I'm
telling you!)
Re: ProtonJ compilation and test failures
Posted by Gordon Sim <gs...@redhat.com>.
On 07/06/2015 04:08 PM, Rafael Schloming wrote:
> Any sort of missing class really should be a compile time exception, which
> I think means you must have stale class files *somewhere*. You could try
> doing a find checkout -name "*.class" just as a sanity check.
I have deleted all the .class files that are generated in the source
tree (and deleted the entire build directory).
The class files are rebuilt for ProtonJInterop, alongside those for
InteropTest and JythonTest in
./tests/target/test-classes/org/apache/qpid/proton/:
ProtonJInterop$1.class
ProtonJInterop.class
ProtonJInterop$Recv.class
ProtonJInterop$Send.class
ProtonJInterop$SendHandler.class
However the test run still reports that it cannot load these.
> Also, it's
> possible something in your local maven repo is somehow coming into play,
> maybe blow that away and rebuild it and/or do an mvn install to be sure
> that remove dependencies aren't out of sync with local code?
I removed everything I could find that was proton related from the mvn
repository, but that didn't help.
Re: ProtonJ compilation and test failures
Posted by Rafael Schloming <rh...@alum.mit.edu>.
Any sort of missing class really should be a compile time exception, which
I think means you must have stale class files *somewhere*. You could try
doing a find checkout -name "*.class" just as a sanity check. Also, it's
possible something in your local maven repo is somehow coming into play,
maybe blow that away and rebuild it and/or do an mvn install to be sure
that remove dependencies aren't out of sync with local code?
--Rafael
On Mon, Jul 6, 2015 at 11:02 AM, Gordon Sim <gs...@redhat.com> wrote:
> On 07/06/2015 02:23 PM, Robbie Gemmell wrote:
>
>> On 6 July 2015 at 14:17, Gordon Sim <gs...@redhat.com> wrote:
>>
>>> On 07/06/2015 01:24 PM, Rafael Schloming wrote:
>>>
>>>>
>>>> Can you try doing an mvn clean and seeing if it is still an issue?
>>>>
>>>
>>>
>>> I see the same thing after mvn clean
>>>
>>>
>> Does cleaning the checkout as a whole make any difference?
>>
>
> Doesn't seem to, no.
>
>
> To preview what woudl be deleted:
>> git clean -n -d -x -e "*.classpath" -e "*.project" -e "*.settings" .
>>
>> To actually delete things:
>> git clean -f -d -x -e "*.classpath" -e "*.project" -e "*.settings" .
>>
>> The -e flags are protecting project files generated by Eclipse...if
>> you dont use it, no need for them.
>>
>>
>
Re: ProtonJ compilation and test failures
Posted by Gordon Sim <gs...@redhat.com>.
On 07/06/2015 02:23 PM, Robbie Gemmell wrote:
> On 6 July 2015 at 14:17, Gordon Sim <gs...@redhat.com> wrote:
>> On 07/06/2015 01:24 PM, Rafael Schloming wrote:
>>>
>>> Can you try doing an mvn clean and seeing if it is still an issue?
>>
>>
>> I see the same thing after mvn clean
>>
>
> Does cleaning the checkout as a whole make any difference?
Doesn't seem to, no.
> To preview what woudl be deleted:
> git clean -n -d -x -e "*.classpath" -e "*.project" -e "*.settings" .
>
> To actually delete things:
> git clean -f -d -x -e "*.classpath" -e "*.project" -e "*.settings" .
>
> The -e flags are protecting project files generated by Eclipse...if
> you dont use it, no need for them.
>
Re: ProtonJ compilation and test failures
Posted by Robbie Gemmell <ro...@gmail.com>.
On 6 July 2015 at 14:17, Gordon Sim <gs...@redhat.com> wrote:
> On 07/06/2015 01:24 PM, Rafael Schloming wrote:
>>
>> Can you try doing an mvn clean and seeing if it is still an issue?
>
>
> I see the same thing after mvn clean
>
Does cleaning the checkout as a whole make any difference?
To preview what woudl be deleted:
git clean -n -d -x -e "*.classpath" -e "*.project" -e "*.settings" .
To actually delete things:
git clean -f -d -x -e "*.classpath" -e "*.project" -e "*.settings" .
The -e flags are protecting project files generated by Eclipse...if
you dont use it, no need for them.
Re: ProtonJ compilation and test failures
Posted by Gordon Sim <gs...@redhat.com>.
On 07/06/2015 01:24 PM, Rafael Schloming wrote:
> Can you try doing an mvn clean and seeing if it is still an issue?
I see the same thing after mvn clean
Re: ProtonJ compilation and test failures
Posted by Rafael Schloming <rh...@alum.mit.edu>.
Can you try doing an mvn clean and seeing if it is still an issue?
A class entirely missing like that is usually due to mvn not recompiling
everything that is impacted by a given change.
--Rafael
On Mon, Jul 6, 2015 at 8:11 AM, Gordon Sim <gs...@redhat.com> wrote:
> All the ProtonJInterop tests fail for me, and the python-test then hangs.
> The error for each is something like:
>
> 2: proton_tests.reactor_interop.ReactorInteropTest. \
>> 2: Error: Could not find or load main class
>> org.apache.qpid.proton.ProtonJInterop
>> 2: test_protonc_to_protonj_1
>> ........................................... fail
>> 2: Error during test: Traceback (most recent call last):
>> 2: File "/home/gordon/projects/proton-git/tests/python/proton-test",
>> line 360, in run
>> 2: phase()
>> 2: File
>> "/home/gordon/projects/proton-git/tests/python/proton_tests/reactor_interop.py",
>> line 141, in test_protonc_to_protonj_1
>> 2: self.protonc_to_protonj(1)
>> 2: File
>> "/home/gordon/projects/proton-git/tests/python/proton_tests/reactor_interop.py",
>> line 124, in protonc_to_protonj
>> 2: assert(java_thread.result == 0)
>> 2: AssertionError
>> 2: proton_tests.reactor_interop.ReactorInteropTest. \
>> 2: Error: Could not find or load main class
>> org.apache.qpid.proton.ProtonJInterop
>>
>
>
Re: ProtonJ compilation and test failures
Posted by Gordon Sim <gs...@redhat.com>.
All the ProtonJInterop tests fail for me, and the python-test then
hangs. The error for each is something like:
> 2: proton_tests.reactor_interop.ReactorInteropTest. \
> 2: Error: Could not find or load main class org.apache.qpid.proton.ProtonJInterop
> 2: test_protonc_to_protonj_1 ........................................... fail
> 2: Error during test: Traceback (most recent call last):
> 2: File "/home/gordon/projects/proton-git/tests/python/proton-test", line 360, in run
> 2: phase()
> 2: File "/home/gordon/projects/proton-git/tests/python/proton_tests/reactor_interop.py", line 141, in test_protonc_to_protonj_1
> 2: self.protonc_to_protonj(1)
> 2: File "/home/gordon/projects/proton-git/tests/python/proton_tests/reactor_interop.py", line 124, in protonc_to_protonj
> 2: assert(java_thread.result == 0)
> 2: AssertionError
> 2: proton_tests.reactor_interop.ReactorInteropTest. \
> 2: Error: Could not find or load main class org.apache.qpid.proton.ProtonJInterop
Re: ProtonJ compilation and test failures
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <rh...@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 <ro...@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 <rh...@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.gemmell@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
>> >>
>>
Re: ProtonJ compilation and test failures
Posted by Rafael Schloming <rh...@alum.mit.edu>.
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 <ro...@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 <rh...@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.gemmell@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
> >>
>
Re: ProtonJ compilation and test failures
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <rh...@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 <ro...@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
>>
Re: ProtonJ compilation and test failures
Posted by Rafael Schloming <rh...@alum.mit.edu>.
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 <ro...@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
>