Integrate Python tests with mvn
---
Key: QPID-401
URL: https://issues.apache.org/jira/browse/QPID-401
Project: Qpid
Issue Type: Improvement
Components: Maven build system
Reporter: Martin
I think we should be aiming to be identical in every respect in which
it is reasonable to do so. That is to say that, if there is not a very
good reason for the API being different among the clients, then why
make it different? There may need to be occasional differences to
cater for the
Test failures in java/client tests seem to be intermittent. I got this one:
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.721 sec
Running org.apache.qpid.test.unit.basic.PropertyValueTest
Completed without failure
java.lang.Exception: Stack trace
at
And the same one again on a different test:
Running org.apache.qpid.test.unit.basic.TextMessageTest
Completed without failure
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1158)
at
The major issue is not the naming but the struture. I agree that we should
have some API which is common across the different languages which probably
maps pretty closely to the AMQP protocol iteself (the protocol looking as
much like an API as it is possible for a protocol to do). However, for
Yes, thats worth mentioning too. The JMS api will always be different
from the close to the protocol AMQ/QPID api. Currently the java
client provides both APIs, with JMS implemented on top of the QPID one
(more or less). The JMS API cannot be implemented in other lanaguges,
because Sun forbids
I'd like to propose the addition of Tomas Restrepoas a Qpid committer.
He has contributed extensively on the .NET client, both in code and mailing
list terms.
This vote will stay open until COP Tues 13th March. Please cast your votes.
[ ] Add Tomas as a Qpid committer
Regards,
Marnie
I'd like to propose the addition of Rupert Smith as a Qpid committer.
He has contributed extensively on the .NET client and also to the Java code,
both in code and mailing list terms.
This vote will stay open until COP Tues 13th March. Please cast your votes.
[ ] Add Rupert as a Qpid committer
I'd like to propose the addition of Kevin Smith as a Qpid committer.
He has contributed significantly on the Java Broker Client (particularly
in the thorny area of SSL/Config), both in code and mailing list terms.
This vote will stay open until COP Tues 13th March. Please cast your votes.
[ ]
[+1 ] Add Tomas as a Qpid committer
Regards,
Bhupendra Bhardwaj
On 3/6/07, Marnie McCormack [EMAIL PROTECTED] wrote:
I'd like to propose the addition of Tomas Restrepoas a Qpid committer.
He has contributed extensively on the .NET client, both in code and
mailing
list terms.
This vote will
Agree on the tests passing remarks. We do really need continuous build
across the board :-(
M
+1 From me. (interop spec will be uploaded to the wiki very very soon).
On 3/6/07, Robert Godfrey [EMAIL PROTECTED] wrote:
From me:
*[+1] M2 Release inc Java, C++, .NET
[ 0] Python and Ruby clients
In particular I think we *must* release an interoperable Java Broker, Java
Client, .NET
[+1] Add Rupert as a Qpid committer
Reduce excess output during tests
-
Key: QPID-405
URL: https://issues.apache.org/jira/browse/QPID-405
Project: Qpid
Issue Type: Improvement
Affects Versions: M1
Reporter: Martin Ritchie
Reduce excess output during tests
-
Key: QPID-404
URL: https://issues.apache.org/jira/browse/QPID-404
Project: Qpid
Issue Type: Improvement
Affects Versions: M1
Reporter: Martin Ritchie
[+1] Add Tomas as a Qpid committer
[+1] Add Rupert as a Qpid committer
[+1] Add Kevin as a Qpid committer
On 06/03/07, Gordon Sim [EMAIL PROTECTED] wrote:
[+1] Add Kevin as a Qpid committer
+1 from me.
Regards
Tejeswar
-Original Message-
From: Marnie McCormack [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 06, 2007 6:41 AM
To: qpid-dev@incubator.apache.org
Subject: [VOTE] Qpid M2 Release
Hi All,
I there are now some compelling motivations for releasing an M2.
I'd like
Working copy of the spec is now at:
http://cwiki.apache.org/confluence/display/qpid/Interop+Testing+Spec.
This describes the centralized approach advocated by Gordon. One
important difference with Gordon's proposal is that the assign role
(and some other control messages) are not sent out on a
Oops, its at:
http://cwiki.apache.org/confluence/display/qpid/Interop+Testing+Specification
On 3/6/07, Rupert Smith [EMAIL PROTECTED] wrote:
Working copy of the spec is now at:
http://cwiki.apache.org/confluence/display/qpid/Interop+Testing+Spec.
This describes the centralized approach
[+1] Add Kevin as a Qpid committer
--
Martin Ritchie
On 06/03/07, Alan Conway [EMAIL PROTECTED] wrote:
On Tue, 2007-03-06 at 12:32 +, Martin Ritchie wrote:
On 05/03/07, Alan Conway [EMAIL PROTECTED] wrote:
I'll be merging the 0-9 C++ branch (Jira QPID-400) soon, speak up if you
know of any outstanding issues. The plan is to merge python
+1 Add Rupert as a Qpid committer
[
https://issues.apache.org/jira/browse/QPID-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Ritchie reassigned QPID-397:
---
Assignee: Martin Ritchie
Client closeure can be processed before final message ack.
[
https://issues.apache.org/jira/browse/QPID-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Ritchie resolved QPID-405.
-
Resolution: Fixed
Resolved at r515128
Reduce excess output during tests
Addressing these points in a random order:
1) Changing the spec file:
I think we should ensure that all our changes are in a separate XML file
from the official AMQP spec. We can then overlay these on top of the
official spec at code generation time. There is some ability in the code
[
https://issues.apache.org/jira/browse/QPID-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Ritchie resolved QPID-355.
-
Resolution: Fixed
Resolved at r515127
Closing a consumer does not ensure messages delivery will
+1 - Kim can answer the question on the code generator.
On Tue, 2007-03-06 at 15:58 +, Robert Godfrey wrote:
Addressing these points in a random order:
1) Changing the spec file:
I think we should ensure that all our changes are in a separate XML file
from the official AMQP spec. We
Forgot to say +1 to M2 release including C++ provided we work out the
branching issues.
---BeginMessage---
We'll need an M2 release branches to isolate M2 from turbulence caused
by the 0-9 merge. We can defer branching for some components. Here's
what I propose for the parts I'm merging:
spec:
[
https://issues.apache.org/jira/browse/QPID-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478458
]
Martin Ritchie commented on QPID-403:
-
Initial steps implemented.
Implement Basic.Reject
On Mon, 2007-03-05 at 16:19 +, Rupert Smith wrote:
I notice that you plan to rename files after classes? If you are doing
a big rename, it might also be advantageous to try and rename towards
having a consistent client API whilst you are at it.
Not at this point - I'm just restoring the
On Tue, 2007-03-06 at 15:58 +, Robert Godfrey wrote:
I think we should ensure that all our changes are in a separate XML
file
from the official AMQP spec. We can then overlay these on top of the
official spec at code generation time.
Agreed. This minimized the possibility that changes
I have tried out a few different build servers. I started by looking
at this feature matrix (probably not entirely complete or up to date):
http://damagecontrol.codehaus.org/Continuous+Integration+Server+Feature+Matrix
As you can see there are two that have more green ticks than the
others.
Can I request as few branches as possible? Ideally, just the one for
the entirety of M2. I'm already starting to lose track of what is in
what branch.
On 3/6/07, Alan Conway [EMAIL PROTECTED] wrote:
We'll need an M2 release branches to isolate M2 from turbulence caused
by the 0-9 merge. We can
[
https://issues.apache.org/jira/browse/QPID-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Ritchie resolved QPID-389.
-
Resolution: Fixed
The prefetched messages are now rejected on closure so that they can be requeued
+1 on the free license - but what are the conditions on its use? Obviously
any continuous build system will have to be hosted on some equipment. How
many installations is the license offer good for? If an instance is to be
hosted inside the company which employs one of the contributors what
[
https://issues.apache.org/jira/browse/QPID-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Ritchie resolved QPID-404.
-
Resolution: Fixed
duplicate of QPID-405 :resolved at r515128
Reduce excess output during tests
On 3/6/07, Martin Ritchie [EMAIL PROTECTED] wrote:
On 06/03/07, Rajith Attapattu [EMAIL PROTECTED] wrote:
Folks,
I think it's a good time to get the ball rolling on the release plan for
post M2.
Here are some suggestions to start of with.
Visioning:
I suggest to move away from Mx (or
Test clients are just going to send a pass/fail to the coordinator. In
the failure case they can put whatever text they like in the message
body, by way of explanation (log, stack trace, whatever). Coordinator
will take care of outputing the results to XML.
On 3/6/07, Alan Conway [EMAIL
Martin Ritchie wrote:
Can the Authors of the Ruby/Python speak for its current state? If we
are to release python and ruby clients then all the clients should
interop.
Python should be good to go once the interop issues mentioned in another
thread are addressed. To my knowledge it's been a
On 06/03/07, Rajith Attapattu [EMAIL PROTECTED] wrote:
Folks,
I think it's a good time to get the ball rolling on the release plan for
post M2.
Here are some suggestions to start of with.
Visioning:
I suggest to move away from Mx (or milestones) releases and use a numbering
scheme like 0.9x.x.
One thing to add (or rather subtract) I think we should either emove from
the distribution or specifically disclaim any claims of functionality for
the Java Clustered Broker. To my knowledge no-one has been testing this for
a while, and a number of tests have simply been commented out rather
On Mon, 2007-03-05 at 10:21 +, Rupert Smith wrote:
As for gathering reports, I was thinking that each test (sender part)
would report pass/fail (message body containing reason for failure in
failure cases) to the coordinator, of which there is only one, and it
will write out the xml
Hi,
I looked at the java/systests module and some of the tests were failing.
This module didn't have a test directory so the tests were not getting run
thorugh maven.
To get these tests running through mvn, I will create test directory and
some tests suite to run some of the tests in the main
[+1] Add Tomas as a Qpid committer
Robert
Rupert Smith wrote:
http://cwiki.apache.org/confluence/display/qpid/Interop+Testing+Specification
Control of tests is still done through direct interaction between
clients. The aim of the centralized approach was to restrict all control
traffic to occur between a test client and the
Rafael Schloming wrote:
Martin Ritchie wrote:
Can the Authors of the Ruby/Python speak for its current state? If we
are to release python and ruby clients then all the clients should
interop.
Python should be good to go once the interop issues mentioned in another
thread are addressed. To my
On 06/03/07, Marnie McCormack [EMAIL PROTECTED] wrote:
We also need to introduce a new AMQP protocol version across the board, and
it makes good sense to get M2 out there before we do this.
I think this is key. Once we get into a protocol change cycle it could
be some time before we can do
On Tue, 2007-03-06 at 19:31 +, Robert Greig wrote:
[ ] Python and Ruby clients
+0 since I haven't used these at all. Can anyone who has used the Ruby
client (for anything non-trivial) post their experiences? Similarly
for the Python client?
Python is probably the most extensively
I'm also seeing this failure intermittently. Is someone looking into it?
A quick search didn't turn up a JIRA for it. I get the following output
at the end of mvn test and then it just hangs:
---
T E S T S
On Tue, 2007-03-06 at 12:14 -0500, Rajith Attapattu wrote:
I suggest we don't get to caught up in the nomeclature of our
releases. Moving to a numbering scheme similar to AMQP is perhaps a
reasonable approach. We started using Mx as that is the Incubator way.
+1 on not getting caught up.
[+1] M2 Release inc Java, C++, .NET
[+1] Python
[0] Ruby clients - don't know status.
Alan,
On Tuesday 06 March 2007 16:50, Alan Conway wrote:
On Tue, 2007-03-06 at 12:14 -0500, Rajith Attapattu wrote:
I suggest we don't get to caught up in the nomeclature of our
releases. Moving to a numbering scheme similar to AMQP is perhaps a
reasonable approach. We started using Mx
On Tue, 2007-03-06 at 11:38 +, Martin Ritchie wrote:
On 05/03/07, Alan Conway [EMAIL PROTECTED] wrote:
I'll be merging the 0-9 C++ branch (Jira QPID-400) soon, speak up if you
know of any outstanding issues. The plan is to merge python first for
the tests (branch python speaks both old
Building off trunk I'm also getting
Running org.apache.qpid.test.unit.transacted.CommitRollbackTest
Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 5.015 sec
FAILURE!
testSend2ThenRollback(
org.apache.qpid.test.unit.transacted.CommitRollbackTest)
Time elapsed: 0.078 sec
56 matches
Mail list logo
