So, I'm not really sold on the benefits of moving the java and cpp trees to the top level to be peers of proton. From a cost benefit perspective, the cost is probably fairly low... but I'm not sure if there is any real benefit.
As far as I can see the only positive is that we no longer have a sub-project of Qpid in a directory called "qpid"... but now we have a couple of sub-projects that have no logical cohesion, but do some level of interdependency, and a history of releasing as a unit. My view is that this simply takes us from having one messed up top level sub-project, to having two (which actually probably still want to stick to a joint release cycle anyway). Rather than putting "java" at the top level, if we were wanting to do a quick-ish and dirty-ish change in the short-ish term, then I would prefer to move the JMS client, and Java Broker to be separate top level components. I would suggest that the Java Broker have a dependency on the Java Client, and the Java "Common" code live in the client (ideally I'd want to move the shared transport code into a proper library, but that would probably be a bigger ask). Having said all of the above, I'd be prioritising work on the website and work on proton above re-orging the components for the moment. On the java side I would proably suggest altering the directory structure when we start looking to build the new JMS client based on Proton, and integrating Proton code into the Java Broker. -- Rob On 22 January 2013 21:58, Justin Ross <[email protected]> wrote: > I think this is productive discussion! Just to be clear, I'm not bent > out of shape about any of this. I want more and more people to get > engaged solving it. > > On Tue, Jan 22, 2013 at 2:08 PM, Alan Conway <[email protected]> wrote: > >> I think the general idea of having other libraries and services at the > same > >> level as proton makes a lot of sense... however given the way that the > Java > >> tree is constructed (I can't speak for the C++), it'd be a little hard > to > >> arrange right now and having a top level entry corresponding to "java" > >> probably wouldn't help with the silo-ing which you describe below > (moreover > >> it really doesn't make much sense from a user perspective either). > >> > >> So a directory structure which had top level entries something more like > >> > >> ** proton > >> ** Java broker > >> ** C++ broker > >> ** JMS client > >> ** Messaging API client(s) > >> ** AMQP proxy > >> ** AMQP router > >> ** Management Console > > I like this very much. But when I was looking at this I took a > pragmatic turn: extricating the common dependencies is hard, so why > not just leave the cpp and java trees as is (albeit moved up to the > level of proton)? They're already quite independent, and there is a > lot of "integration" invested in them as they are. > > So I thought, we could keep them as they are, maintain them, and > refocus our energy on things like a new independent JMS client (on > proton) and AMQP routers (on proton). On balance, it seems like the > neatest way to make a break, balancing our desire to not break stuff > with our desire to press forward with a new model. > > I understand the argument in favor of zero disruption. To me that's > about timing; it's something you do only rarely. But I happen to > think this year is the right time to set down a new pattern and come > out with a splash. > > Justin > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
