Hi All, I have some strong views here, and reading them please bear in mind I'm at the sharp end of approx 30 user projects built on Qpid ....... (very sharp right now :-)
- more JARs and interdependencies is not a good thing for our users - we do not want to mess with the build system just now, we haven't even really finished getting the 'new' ant one up to full throttle and I don't think this is the most important area for effort ? - making more things for clients to depend on is bad news - I definitely think the mgt stuff should live outside our existing client structure I can see both sides of the reorg discussion, but I'm heavily influenced by limiting this type of change unless there's a clear return on the investment - we've been on the go for 2 years and are already on our 3rd set of build scripts etc on the Java side. So, there may be a logical reason for making changes - but unless there's a really compelling reason to change *again*, then pleeeaaase let's not. I haven't yet updated our dev build page to say 'M1 instructions', 'M2+ Instructions', 'M3 Instructions'. Argh. So, come forth with your 'this is the current quantifiable pain' arguments for the reorder or let's make it a golden goal for sometime post-M4 ! We have LOTS and LOTS of JIRAs, let's do them first !!! Phew. I'm going to step away from the keyboard now. Don't all shout back at once. Bfn, Regards, Marnie On Wed, Oct 1, 2008 at 4:15 PM, Rafael Schloming <[EMAIL PROTECTED]> wrote: > Arnaud Simon wrote: > >> ----- "Rafael Schloming" <[EMAIL PROTECTED]> wrote: >> >> I kind of agree but following this reasoning this would mean that we >>>> >>> need a standalone jar for the jms client. >>> I'm not sure I follow. We *do* have a standalone jar for the jms >>> client. Or we did before the management stuff was put under client. >>> >>> --Rafael >>> >> >> What I mean that not all applications may use JMS as this a layer on top >> of AMQP. So if we follow your reasoning we should have a jar for the AMQP >> client and a jar for the JMS implementation. >> > > I agree, with the one caveat that I don't think it's a good idea to > consider protocol level APIs public until AMQP 1.0 is released. > > --Rafael > >
