Rupert, As Jonathon pointed out, we should have both clients in the trunk in parallel until the new client has reached a stage of maturity that is satisfactory to all parties. Comments inline
Regards, Rajith On 6/13/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
Please add: 0. Ensure the existing client unit test suite, sys tests, integration
tests
and performance tests, runs against the refactored client code before the existing client code is 'broken'.
[RA] We should make a consious effort to ensure that all sys tests, integrations and perf tests are converted to run against the new client. However this is also a good time to have some meaningful discussion on how we should organize our unit,sys test and perf test. Some of the current unit tests are not strictly unit tests and are more integration tests. Therefore I plan to include more unit tests. Thank you Rupert for highlighting this very important issue.
If necessary/possible convert some tests that use the existing Java AMQP
API
to run through the JMS API. 0.5. Identify any JIRAs for M2 that it would be sensible to write tests
for,
and make sure tests for them exist for M2 and the new client code.
As I mentioned, any important modifications/improvements should be accomadated in the new client where is makes sense. Some of these changes might not be applicable due to protocol changes/improvements and/or new client architecture.
0.9. Ensure that any existing requirements for the current client code are going to be carried forward to the refactoring. At the moment, I can think of: - Ensure retrotranslation to Java 1.4 will work.
[RA] It's a reasonable request. How are u guys supporting it currently? Are u using a retrotranslator jars?
On 13/06/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > Hi Folks, > > I think we've gotten to the point that we have rough consensus, and it's > clear how to move forward. > > I think there is broad agreement on the following goals: > > 1. We should have a low level client API that maps directly to the AMQP > protocol across all language implementations. > This will make it easier to keep language bindings consistent and to
test
> them. > > 2. Early adopters can work with the low level client API, with the > explicit > understanding that this API is likely to change until the protocol > stabilizes. > > 3. The JMS implementation should be built on the Java AMQP client,
which
> will make it easier to keep it consistent with the other language > bindings and to test. > > 4. The existing Java client code needs to be re-factored. > The current prototype available has reused and rearranged existing code
as
> much as possible. > > 5. We should consider how to provide AMQP functionality beyond what JMS > offers. > Several strategies were explored, including extending JMS and designing > the > low level AMQP client so that it can be used together with JMS using > casting. > > Based on this, I think we should do the following: > > 1. Refactor the existing Java client code so that it implements JMS > functionality on top of a low level AMQP API. > > 2. Identify a list of key bug fixes/JMS extensions in the M2
branch,and
> reflect these in the new Java client code. > > Unless I hear otherwise, this is the plan I intend to pursue. > > Rajith >
