Rupert Smith wrote:
Thanks for taking time to read through and provide feedback Gordon.
Thanks for taking the time to write up a good spec for the rest of us to
read; thats the real work! It's going to be of huge benefit to have this
framework in place, your efforts are very much
Alan Conway wrote:
I'm still seeing many python test failures against the java broker on
trunk.
They work for me. A lot of the errors you are seeing seem to indicate
some odd problems.
There are some connection refused errors which would seem to indicate a
broker crash or something(?).
I get the following error when running 'mvn -Pfastinstall'
[INFO] [surefire:test {execution: surefire-it}]
[INFO] Surefire report directory:
/home/gordon/qpid/trunk/qpid/java/client-java14/target/surefire-reports
[INFO]
Something wrong there with the client-1.4 pom. My intention was to
make it avoid running any tests by default, unless you set up a path
to java 1.4 in you local settings.xml. The reason being, that I can't
make any assumptions about whether or not a java 1.4 jdk is installed
or where it might be
On 06/03/07, Alan Conway [EMAIL PROTECTED] wrote:
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
On 07/03/07, Martin Ritchie [EMAIL PROTECTED] wrote:
On 06/03/07, Alan Conway [EMAIL PROTECTED] wrote:
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
I've commented the client-java14 module out of the top level pom, so
its not in the build by default anymore. It is doing something very
wacky to maven. Will add back in once it is in a cleaner state.
Rupert
On 3/7/07, Rupert Smith [EMAIL PROTECTED] wrote:
Something wrong there with the
Do we need the snapshot repositories on our poms? Maven takes a long
time to check for updates of various modules that I didn't think we
were using. e.g.
org.apache.maven.archiva:archiva:1.0-SNAPSHOT
org.apache.maven.archiva:archiva-utils:1.0-SNAPSHOT
--
Martin Ritchie
Seems like codehaus mojo are already on the case with the
retrotranslator plugin. A concrete release should be coming out soon.
On 3/7/07, Rupert Smith [EMAIL PROTECTED] wrote:
Another question is, what snapshots need to be resolved in order to do
a release? Is it only dependancies that form
[+1] Java, C++,
[+1] Python
[0] .NET and Ruby clients - don't know status.
Rajith
On 3/6/07, Alan Conway [EMAIL PROTECTED] wrote:
[+1] M2 Release inc Java, C++, .NET
[+1] Python
[0] Ruby clients - don't know status.
[+1] M2 Release inc Java, C++, .NET
[+1] Python
[0] Ruby clients - don't know the status
Regards,
Bhupendra Bhardwaj
Martin Ritchie wrote:
On 06/03/07, Alan Conway [EMAIL PROTECTED] wrote:
FAILED (failures=5, errors=14)
Alan your java code needs an SVN update. These were the errors I was
seeing before I did my recent commit. I shall do an update and ensure
that the trunk passes all the python tests.
The
Rupert Smith wrote:
I see your point, shifting as much stuff into the coordinator as
possible. I had a suspicion I was making the test case interaction
between the test clients too complex.
Don't forget there are *two* points for centralizing test control code.
One is the co-ordinator, the
Gordon Sim wrote:
Rupert Smith wrote:
Thanks for taking time to read through and provide feedback Gordon.
Thanks for taking the time to write up a good spec for the rest of us
to read; thats the real work! It's going to be of huge benefit to have
this framework in place, your efforts are
With the parallel thread on cutting an M2 release, do we want to cut that at
a point before or after you merge 0-9 down to trunk (I would think before,
but if you think the 0-9 branch does 0-8 as well or better than trunk...).
Probably want to co-ordinate so that if people have a lot of pending
From Marnie
We have quite a bit of work to consider/do prior to release including
interop testing, docs etc. Happy to raise JIRAs (or assist the release
manager) for an M2 set of tasks if we proceed.
From Alan
ll be merging the 0-9 C++ branch (Jira QPID-400) soon, speak up if you
ow of any
Alan Conway wrote:
Don't forget there are *two* points for centralizing test control code.
One is the co-ordinator, the other is the test runners that will
actually be running the tests.
My view is that anything that can be done in the co-ordinator should be
done there. The test runners
I share your concerns, but take the opposite view - i.e. +1 for the release.
I think if we do not have a release now, we will be unable to release again
for some time due to the immense amount of changes that we need to put in
for the upcoming AMQP 0-10 spec, and for introducing clustering and
I don't think the test clients will need to use
JUnit/CppUnit/WhateverUnit. Mostly they will just be fairly simple
scripts that react to instructions sent by the coordinator. Although,
having said that, you could use *Unit if you like. I'm just not sure
it adds anything, because these clients
This release is very important for the project as everyone has done so
much good work since M1 and it is precisely why we need to get a good
M2 release done before we have a quite period whilst we sort out our
position for 0-9 and 0-10. I am not against the release in any way I
think we need to
Gordon Sim wrote:
Alan Conway wrote:
Don't forget there are *two* points for centralizing test control
code. One is the co-ordinator, the other is the test runners that
will actually be running the tests.
My view is that anything that can be done in the co-ordinator should
be done there.
My ambition for the M2 release is only to have interop at the basic AMQP
level - that means that we will not be interoperable at the JMS level as
this requires extensions on top of basic AMQP. While we work those
extensions through the AMQP process I don't think we need all the other
clients to
What If:
We find that the M2 branch needs a *lot* of work to get it in shape to
release? This will mean a lot of merging, getting increasingly
difficult as trunk diverges away in the 0.9 direction. Also, isn't it
a good idea to bring trunk up to production quality every now and
again? I agree
In which case, 5 days sounds adequate to me. (not including the weekend!).
Rupert
On 3/7/07, Robert Godfrey [EMAIL PROTECTED] wrote:
My ambition for the M2 release is only to have interop at the basic AMQP
level - that means that we will not be interoperable at the JMS level as
this requires
Alan Conway wrote:
Gordon Sim wrote:
Alan Conway wrote:
Don't forget there are *two* points for centralizing test control
code. One is the co-ordinator, the other is the test runners that
will actually be running the tests.
My view is that anything that can be done in the co-ordinator
On 07/03/07, Rupert Smith [EMAIL PROTECTED] wrote:
In which case, 5 days sounds adequate to me. (not including the weekend!).
Rupert
We'll let people have this weekend off... but let's not make a habit of it
:-)
-- Rob
Robert Godfrey wrote:
Having said that, because of requirements put forward by people actually
using the software, we have built a higher level of interoperability at the
JMS level into the .net and C++ clients, and C++ broker (i.e. extending the
FieldTable to cope with the new types).
The c++
Rupert Smith wrote:
I don't think the test clients will need to use
JUnit/CppUnit/WhateverUnit. Mostly they will just be fairly simple
scripts that react to instructions sent by the coordinator. Although,
having said that, you could use *Unit if you like.
The test clients will need a way to:
-
On 07/03/07, Gordon Sim [EMAIL PROTECTED] wrote:
Robert Godfrey wrote:
Having said that, because of requirements put forward by people actually
using the software, we have built a higher level of interoperability at
the
JMS level into the .net and C++ clients, and C++ broker (i.e. extending
On 07/03/07, Robert Godfrey [EMAIL PROTECTED] wrote:
We need to at least aim to timebox it. I think we need a few days before we
count the votes :-) and then we can set ourselves a limit for how long we
have to get the code in shape for an M2 release. In this we should
concentrate our efforts
The coordinator will only be implemented in one language, once only.
There will be many test clients in all languages, just test clients,
with no coordinator part.
I really don't see what *Unit adds to the test client end. Please note
Alan, we've switched from my original idea of having each
Martin Ritchie wrote:
From Marnie
We have quite a bit of work to consider/do prior to release including
interop testing, docs etc. Happy to raise JIRAs (or assist the release
manager) for an M2 set of tasks if we proceed.
From Alan
ll be merging the 0-9 C++ branch (Jira QPID-400) soon, speak
Rupert Smith wrote:
The coordinator will only be implemented in one language, once only.
There will be many test clients in all languages, just test clients,
with no coordinator part.
I really don't see what *Unit adds to the test client end. Please note
Alan, we've switched from my original
- group related tests together.
Coordinator does this (in the sense that it produces a test suite of
all available combinations of clients and test cases).
- assert expected conditions are met.
Coordinator does this.
- handle unexpected failures.
If clients fail to produce reports, coordinator
On 07/03/07, Alan Conway [EMAIL PROTECTED] wrote:
Martin Ritchie wrote:
From Marnie
We have quite a bit of work to consider/do prior to release including
interop testing, docs etc. Happy to raise JIRAs (or assist the release
manager) for an M2 set of tasks if we proceed.
From Alan
ll be
I think I'd prefer us to say that we'll hold off the merge until next week
so that we can actually get approval for an M2 branch.
I don't think any work should be getting held up... We have two parrallel
streams, the fact that currently one is trunk and the other is 0-9, and
we want to move to
OK - so can we set a date for the creation of the M2 branch, and the merging
of the 0-9 branch down to trunk?
Would early next week (Monday or Tuesday) be OK with everybody for instance?
In the meantime we won't do anything new to trunk other than check in things
we are working on, or fix bugs?
Alan Conway wrote:
- assert expected conditions are met.
My view was that the test clients would not do much in the way of
asserting anything. They would do 'something' and tell the coordinator
they did it (with some details perhaps). The coordinator would assert
that the reports from all
Robert Godfrey wrote:
With the parallel thread on cutting an M2 release, do we want to cut
that at
a point before or after you merge 0-9 down to trunk (I would think
before,
but if you think the 0-9 branch does 0-8 as well or better than
trunk...).
I'd suggest this order:
1. Merge python
Martin Ritchie wrote:
The suggestion wasn't to hold up development for M2 but rather to hold
up M2 release until development has ticked all the boxes we have set
ourselves for M2 release. I understand the desire to get 0.9 on the
trunk and think that should be our main driver just now but we do
Robert Godfrey wrote:
I'm just not sure whether (procedurally) we can make an M2 branch before
we've given people enough time to vote for an M2 release...
Making a branch doesn't commit us to a release, it doesn't even force
anybody to use the branch. It just means the current state of C++ is
The java broker doesn't correctly count the message references so
occasionally we are seeing errors in the tests. I also have to commit
my topic matching exchange which seems stuck at 90% done.
On 07/03/07, Robert Godfrey [EMAIL PROTECTED] wrote:
Can anyone who has oustanding work on the trunk
On Wednesday 07 March 2007 05:56, Rupert Smith wrote:
Another question is, what snapshots need to be resolved in order to do
a release? Is it only dependancies that form part of the distribution,
or do all maven plugin snapshots need to be resolved too?
All plugins that are part of the build.
On 07/03/07, Daniel Kulp [EMAIL PROTECTED] wrote:
On Wednesday 07 March 2007 05:56, Rupert Smith wrote:
Another question is, what snapshots need to be resolved in order to do
a release? Is it only dependancies that form part of the distribution,
or do all maven plugin snapshots need to be
Martin Ritchie wrote:
On 07/03/07, Alan Conway [EMAIL PROTECTED] wrote:
Robert Godfrey wrote:
I'm just not sure whether (procedurally) we can make an M2 branch
before
we've given people enough time to vote for an M2 release...
Making a branch doesn't commit us to a release, it doesn't
Robert Godfrey wrote:
OK - so can we set a date for the creation of the M2 branch, and the
merging
of the 0-9 branch down to trunk?
We don't have to merge the entire branch in one shot, indeed I think
that would be very unwise. I strongly suggest that merging each
sub-project should be a
Robert Godfrey wrote:
I don't think any work should be getting held up... We have two parrallel
streams, the fact that currently one is trunk and the other is
0-9, and
we want to move to the situation where one is M2 and the other is
trunk
doesn't fundamentally change the dynamics of the
Alan Conway wrote:
I propose we use http://www.orcaware.com/svn/wiki/Svnmerge.py to track
merges for us. It will make merging much less error prone. I'm going to
try it out on the 0-9 branch to backmerge and merge python and spec
prior to merging them to trunk. Its endorsed by the svn team and
[
https://issues.apache.org/jira/browse/QPID-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reassigned QPID-407:
---
Assignee: Gordon Sim
order of redelivered messages should be preserved (where possible)
Michael Doberenz wrote:
We have a set of publishers each of which publish messages in order,
and a single durable subscriber. We're not using transactions and
we're set up to use client acknowledgment. If the subscriber is taken
down in between the call of MessageListener.onMessage and
Gordon Sim wrote:
Currently, messages are taken off the queue when sent to consumers then
requeued again (at the end of the queue) if the client fails to
acknowledge them, so yes it is expected in one sense.
Just a quick update on this: I answered based on old knowledge of the
codebase and
I spent some time yesterday bringing the ruby implementation in sync
with the Java broker and adding some tests. I also added a test harness
with a simple run-tests script similar to the python script of the same
name. With these changes the ruby impl now has easily runnable test
coverage for
+1 for Ruby in M2 from me then
On 07/03/07, Rafael Schloming [EMAIL PROTECTED] wrote:
I spent some time yesterday bringing the ruby implementation in sync
with the Java broker and adding some tests. I also added a test harness
with a simple run-tests script similar to the python script of the
Kevin Smith wrote:
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
+1 for ruby from me also.
Robert Godfrey wrote:
+1 for Ruby in M2 from me then
On 07/03/07, Rafael Schloming [EMAIL PROTECTED] wrote:
I spent some time yesterday bringing the ruby implementation in sync
with the Java broker and adding some tests. I also added a test harness
with a simple
The java broker is passing most but not all python tests on the 0-9
branch. Can someone who's been working on the branch take a look and
update the java_failing.txt with the expected failures?
Rafael Schloming wrote:
Kevin Smith wrote:
If there's any tasks you need help with the Ruby broker, let me know.
I've been meaning to get into that code but haven't had the time. Now
that my day job is lightening up, I'd be willing to help out.
snip
And finally if none of those things excite
Alan Conway wrote:
The java broker is passing most but not all python tests on the 0-9
branch. Can someone who's been working on the branch take a look and
update the java_failing.txt with the expected failures?
Please ignore that message, I wasn't running the tests correctly.
Kevin Smith wrote:
Alan Conway wrote:
I propose we use http://www.orcaware.com/svn/wiki/Svnmerge.py to
track merges for us. It will make merging much less error prone. I'm
going to try it out on the 0-9 branch to backmerge and merge python
and spec prior to merging them to trunk. Its endorsed
Rupert Smith wrote:
The only condition they asked for is that we put an acknowledgement on
the project web site.
If RedHat are going to supply a box or two (need Windows and Linux),
available on the internet, that would be ideal. I was thinking of
getting it running here and figuring out if I
Alan Conway wrote:
Kevin Smith wrote:
Alan Conway wrote:
I propose we use http://www.orcaware.com/svn/wiki/Svnmerge.py to
track merges for us. It will make merging much less error prone. I'm
going to try it out on the 0-9 branch to backmerge and merge python
and spec prior to merging them to
On Wed, 2007-03-07 at 14:50 -0500, Alan Conway wrote:
For RPM purposes we need to use the simple numeric version.release up
front so rpm can figure out the ordering, but I think we can safely add
a decorator to meet the apache requirement (RPM experts can you
confirm? I checked the rpm
On Wed, 2007-03-07 at 12:00 -0500, Alan Conway wrote:
Robert Godfrey wrote:
I don't think any work should be getting held up... We have two parrallel
streams, the fact that currently one is trunk and the other is
0-9, and
we want to move to the situation where one is M2 and the other is
On Wed, 2007-03-07 at 16:36 +, Rupert Smith wrote:
Once again, can I request as few branches as possible. Each is a
headache (unless of course I just pretend I don't know its there!).
Please, just the one for M2.
I heard you say this before and I don't understand it - I think you mean
as
On 07/03/07, Andrew Stitcher [EMAIL PROTECTED] wrote:
In theory this seems correct - that is we shouldn't hold up the C++
reorg for the 0-9 merge. But the main reason we haven't done it yet is
that svn tracks renames (and moving stuff around) extremely poorly and,
this to my understanding,
[ ] Vote to accept the following versioning proposal.
Gee, my first call for a vote :)
I have a proposal that I think satisfies Apache, Fedora (and RPM
generally), the desire to show we're nearing release and the desire to
avoid choosing version numbers at random.
Apache considers M numbers
I guess I should say something like
+ 1.0-0.0
Got to admit, deciding on version numbering schemes isn't one of those
things that gets me excited... the reasoning seems good to me (aiming for a
1.0 release) let's see if anyone has any objections...
-- Rob
On 07/03/07, Alan Conway [EMAIL
Robert Greig wrote:
On 07/03/07, Andrew Stitcher [EMAIL PROTECTED] wrote:
In theory this seems correct - that is we shouldn't hold up the C++
reorg for the 0-9 merge. But the main reason we haven't done it yet is
that svn tracks renames (and moving stuff around) extremely poorly and,
this to
Nuno Santos wrote:
Will also need to check regarding the licensing issue... our plan was
to use CruiseControl but I see in the chart that you mentioned -- very
useful, btw -- that it doesn't directly support make, so we have to
see if we can somehow integrate the C++ build with CruiseControl,
69 matches
Mail list logo
