I think there at least 4 themes/sub-topics that have emerged out of this discussion.
1. Common transport strategy 2. High level project goals (ex having a cohesive set of artefacts, reusing components and minimising duplication). 3. Client/Broker Implementation strategies 4. Project source/component dir structure. Perhaps it would be best if we spin off separate threads for each of these sub-topics. Then we could probably focus a bit more on each of those sub topics. If people are happy with that I can volunteer to do start a thread on each of those topics. Rajith On Fri, Mar 25, 2011 at 10:04 AM, <[email protected]> wrote: > On Fri, 25 Mar 2011, Robert Godfrey wrote: > > We could insert a sub-project at the top level while still maintaining the >>> existing structure? For example: >>> >>> .../asf/qpid/trunk/qpid/spec >>> .../asf/qpid/trunk/qpid/cpp >>> .../asf/qpid/trunk/qpid/java >>> .../asf/qpid/trunk/qpid/... >>> >>> .../asf/qpid/qpid-amqp/trunk/common >>> .../asf/qpid/qpid-amqp/trunk/cpp >>> .../asf/qpid/qpid-amqp/trunk/java >>> .../asf/qpid/qpid-amqp/trunk/... >>> >>> This is a fairly common idiom. ActiveMQ do this, for instance : >>> >>> http://svn.apache.org/viewvc/activemq/trunk/ >>> http://svn.apache.org/viewvc/activemq/activemq-protobuf/trunk/ >>> >> >> Andrew. >> >> >> Yeah - I think this is my preferred solution. >> >> To my mind there's probably scope for things that are currently under >> "trunk" to migrate to fully blown sub-projects over time, but I think the >> immediate next step would be to introduce the >> >> /asf/qpid/transport/[trunk|branches|...] >> > > I don't object to subprojects (indeed, it's attractive in many ways), but I > want us to have the bigger conversation about direction, first. > > The directories under qpid/trunk/qpid are already independent subprojects: > > - They don't share code > > - They don't share a build system or a test entry point > > - They interface among themselves only optionally, just like independent > projects do > > - They are largely worked on by independent groups of people > > What they share is apache infrastructure (jira category, mailing lists) and > a release schedule. > > I don't like the pretending. I want qpid to start to move in the direction > of real integration (this has some very tangible benefits), or explicitly > decide that these are independent (in code, apache infrastructure, and > release cycle). > > Naturally, independent projects can have required dependencies, and under > that plan we can increase our code sharing (relative to what we have now) as > the transport intends to do. > > The downside of independent projects is, in a word, integration cost. > Without a common release, source tree, build system, and test harness, the > difficulty of maintaining a stable, coherent distribution is greater. > > Indeed, that's the problem we face right now. For instance, it's not easy > *at all* for a qpid developer to test a change to one qpid component across > the others. > > How do we want it to work? How should we decide? > > Justin > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > >
