I think it would be useful where the work touches on any major areas/changes basic functionality.
At the very least, we should be making it clear that everything we work on going forward should be JIRA'd so we have traceability for testing etc. I'm aware that our JIRAs really only reflect the position with the Java broker. We should have a set for all implementations. I'd also be happy to see people getting acquainted with the Java code by opting to work on some of the simpler tasks that we've put up there now. We know that there will be more complex work coming as a result of AMQP developments, so now is the time to get familiar with what we've got. We do still need to address the issues around keeping in step with the protocol work, but that's for another email :-) Regards, Marnie On 10/16/06, Carl Trieloff <[EMAIL PROTECTED]> wrote:
Question - do we want open JIRA's for work in progress? I though we only wanted to add new work /open issues to JIRA? Carl. Marnie McCormack wrote: Sounds like we need everyone to create JIRAs for all the tasks in progress to avoid disconnect, please ? I've noticed that there are commits going on that don't have matching JIRAs. This isn't ideal, particularly since we are going to need release notes in the near term which would ideally be autogenerated from JIRA. Seems like we need a little more visibility across the piece. Marnie On 10/16/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > > On 10/16/06, Carl Trieloff <[EMAIL PROTECTED]> wrote: > > > > > > Kim has been working on a new generator and updated framing which > should > > be in, in a > > few days. Might be worth waiting for that to eliminate rework. He has > > wiki page on it. > > > > waiting?? I'm done! lol! > > Carl. > > > > Hiram Chirino wrote: > > > Hi, > > > > > > I just wanted to let you guys know that as the first step for > ActiveMQ > > to > > > support the QPID protocol, I made a more decouple version of > marshaling > > > generators that qpid implemented. You can find the work here: > > > > > > https://svn.apache.org/repos/asf/incubator/activemq/sandbox/qpid > > > > > > Major differences between it and the original qpid versions are that > > > (1) it does not depend on MINA, or any of the qpid internals > > > (including the > > > qpid exceptions). > > > (2) it follow the pattern of separating the command logic from the > > > marshalling logic. This is a pattern that has proven useful in our > > > openwire > > > protocol. > > > (3) supports calling a visitor for faster/type safe command > processing > > > (4) command properties now have getters and setters for better > > > encapsulation > > > (5) all commands now inherit from Frame (simplifies and reduces > object > > > creation) > > > > > > Ideally It would be nice if qpid could maintain nicely decoupled > > > marshaling > > > package like this. That way, ActiveMQ could just pick it up and use > it. > > > But it's not a big deal for us to maintain so if it's not picked up, > > > it's > > > not a big deal. > > > > > > The module also includes integration into activemq where we add > > > support for > > > a 'qpid' transport which understands the amqp protocol using the > > > above. A > > > small Main that starts up an ActiveMQ transport proxy was used to > verify > > > that marshallers work. The proxy unmarshalls to the command objects > > > and the > > > forwards which cases the same object to be remarshalled. > > > > > > Now that we can talk the talk.. it should not take long for ActiveMQ > to > > > directly support AMQP also. > > > > > > > > > > -- > Regards, > Hiram > > Blog: http://hiramchirino.com > >
